r 


AD- AO  16  604 


A STUDY  OF  COMMUNICATIONS  FOR  IilE  SEISMIC  DATA 
COLLECTION  NETWORK 

Howard  W.  Briscoe 

Bolt  Beranek  and  Newman,  Incorporated 


Prepared  for: 

Air  Force  Technical  Applications  Center 
Advanced  Research  Projects  Agency 


30  June  1975 


DISTRIBUTED  BY: 


National  Technical  Information  Service 
U.  S.  DEPARTMENT  OF  COMMERCE 


J 


THIS  DOCUMENT  IS  BEST 
QUALITY  AVAILABLE.  THE  COPY 
FURNISHED  TO  DTIC  CONTAINED 
A SIGNIFICANT  NUMBER  OF 
PAGES  WHICH  DO  NOT 
REPRODUCE  LEGIBLY. 


■ 

i 


310116 

BOLT  BERANEK  AND  NEWMAN  me 


CONSULTING  • DEVELOPMENT  • RESEARCH 


Report  No.  3109 


FINAL  REPORT 

A STUDY  OF  COMMUNICATIONS  FOR 
THE  SEISMIC  DATA  COLLECTION  NETWORK 


30  June  1975 


APPROVED  FOR  PUBLIC  RELEASE. 
DISTRIBUTION  UNLIMITED. 


i 


Prepared  For: 


VELA  Sei  sinological  Center 
312  Montgomery  Street 
Alexandria,  Virginia  22314 


Sponsured  by  the  Advanced  Research  Projects  Agency 
ARPA  Order  No.  2551 


Cambridge  Washington,  d c.  Chicago  Houston  ios  angeies  san  francisco 


Report  No.  3109 


Bolt  Beranek  and  Newman  Inc. 


FINAL  REPORT 

A STUDY  OF  COMMUNICATIONS  FOR 
THE  SEISMIC  DATA  COLLECTION  NETWORK 


30  June  1975 


PRINCIPAL  INVESTIGATOR:  Howard  W.  Briscoe 

Telephone  (617)  491-1850  Ext.  415 


This  research  was  supported  by  the 
Advanced  Research  Projects  Agency  of  the 
Department  of  Defense  and  was  monitored  by 
AFTAC/VSC , Patrick  AFB  FL  32925, 
under  Contract  No.  F08606-75-C-0017 


AFTAC  Project  Authorization  No.  VELA  T/5701/BETR 

Program  Code  No.  5F10 

Effective  Data:  1 August  1974 

Total  Amount  of  Contract:  $70,000.00 

Expiration  Date:  30  June  1975 


The  views  and  conclusions  contained  in  this  document  are 
those  of  the  authors  and  should  not  be  interpreted  as 
necessarily  representing  the  official  policies,  either  expressed 
or  implied,  of  the  Advanced  Research  Projects  Agency,  the 
Air  Force  Technical  Applications  Center,  or  the  U.  S.  Governm 


Prepared  by: 

Computer  Systems  Division 
Bolt  Beranek  and  Newman  Inc. 
Cambridge,  Massachusetts  02138 


APPROVED  FOR  PUBLIC  RELEASE.  DISTRIBUTION  UNLIMITED. 


UNCLASSIFIED 

SECURITY  CLASSIFICATION  of  This  PAOE  (Whon  Doto  Entotod) 

„ REPORT  DOCUMENTATION  PAGE 

READ  INSTRUCTIONS 
BEFORE  COMPLETING  FORM  . 

2.  GOVT  ACCESSION  NO 

S.  RECIPIENT'S  CATALOG  NUMBER 

4.  TITLE  (mtd  Ajbtlllo) 

Final  Report:  A Study  of  Communications  For 

The  Seismic  Data  Collection  Network 

V TYRE  OF  RERORT  « PERIOD  COVERED 

Final:  8/1/74-6/30/75 

1.  PERFORMING  ORG.  REPORT  NUMBER 

BBN  Repgjrt  No.  3109 

7.  AUTHORf*; 

Howard  W.  Briscoe 

t.  contract  or  grant  number.*; 

F08606-75-C-0017 

9 PERFORMING  ORGANIZATION  NAME  AND  ADDRESS 

Bolt  Beranek  and  Newman  Inc. 

50  Moulton  Street 
Cambridge » MA  02138 

»0  PROGRAM  ELEMENT.  PROJECT.  TASK 

AREA  A WORK  UNIT  NUMBERS  . 

Program  Code  //5F10  * 

Project  //VELA  T/5701/BETR  j 

11.  CONTROLLING  OFFICE  NAME  AND  ADDRESS 

Air  Force  Eastern  Test  Range  (AFSC) 
R & D Contracts  Division  (PMRB) 
Patrick  AFB  FL  32925 

12.  REPORT  DATE  I 

30  June  1975  | 

19.  NUMBER  OF  PAGE^ 

■w  / 3 C 

• 4 MONITORING  AGENCY  name  a ADDRESS/"//  dllloront  Irom  Controlling  Olllco) 

AFTAC/VSC 

Patrick  AFB  FL  32925 

is.  SECURITY  CLASS,  (ol  thlo  roport) 

UNCLASSIFIED 

IS*.  OECLASSI  Fl  CATION/ DOWNGRADING 
SCHEDULE 

1«.  DISTRIBUTION  STATEMENT  (ol  thlo  Roport)  j 

APPROVED  FOR  PUBLIC  RELEASE.  DISTRIBUTION  UNLIMITED. 


17  DlSTPiBuTlON  STATEMENT  (ol  fh*  obatroct  Bfaa A 20,  II  dllloront  Imm  Roport) 


I 


?8  SUPPLEMENTARY  notes 


19.  KEY  WOROS  IConflnu*  on  rtm*  ildt  II  nocooomry  ond  >dontHy  by  bio  cl  numbor) 

Seismology  Seismic  Network 

Computer  Networks 
Data  Communication 
Packet  Switching 

—Seismic  Dala 

20  ABSTRACT  (Contlnoo  on  rovoroo  oldo  H hoc ooomry  and  Idontlly  by  block  numbor) 

This  report  pre  ints  the  results  of  studies  performed  to  support  the 
implementation  of  a worldwide  seismic  data  collection  network  using 
a mix  of  ARPA  Network  and  leased  line  communications.  Host  level 
protocols  for  the  ARPA  Network  links  are  specified.  An  analysis  of 
the  traffic  generated  by  the  seismic  data  subnet  identified  potential 
limits  imposed  by  the  bandwidth  and  buffer  capacity  at  two  nodes  of  the 
network.  Operational  monitoring  and  diagnostic  procedures  are  recommended  . 


DD  , 1473  SO.TION  OF  1 NOV  88  IS  OBSOLETE  ' UNCLASSIFIED 


/ SECURITY  CLASSIFICATION  OF  THIS  PACE  (Whon  Doto  Entofod) 


UNCLASSIFIED  

tteublTV  CLAWnCATtOW  OF  THtt  PAMt/Hi  B*m  , 

ABSTRACT  CONT,  , J ‘ J J , 

A backup  plan  for  the  system  design  is  developed  in  case  error  rates 

in  local  communications  to  the  seismic  stat  uns  are  excessive.  Design 

specifications  for  the  Seismic  Private  Line  Interface  computer  for 

interfacing  existing  seismic  station  controllers  to  the  ARPA  Network 

are  included  as  an  appendix. 


Report  No.  3109 


Bolt  Beranek  and  Newman  Inc. 


SUMMARY 

The  effort  under  this  contract  consisted  of  four  tasks 
intended  to  verify  the  design  of  the  seismic  data  collection 
network  and  to  support  the  network  implementation  efforts. 

Task  I 

This  task  consisted  of  maintenance  and  verification  of 
the  Host-to-Host  protocols  to  be  used  on  the  ARPA  Network  paths 
of  the  seismic  data  network.  The  protocol  maintenance  function 
has  involved  coordinating  protocol  changes  found  to  be  convenient 
for  implementation  of  the  Host  programs  on  the  various  Host 
computers . 

Both  experimental  and  analytical  Techniques  were  used  to 
verify  the  protocol  designs.  As  expected,  it  was  found  that  the 
total  proposed  seismic  traffic  would  exceed  the  reliable  capacity 
of  the  existing  ARPA  Network  topology.  The  network  topology 
is  routinely  reviewed  and  revised  to  account  for  changing 
loads  so  this  problem  will  be  remedied  in  the  normal  course  of 
network  operation.  The  study  revealed  a more  serious  bottleneck 
in  the  reassembly  buffer  space  available  in  the  IMPs  at  SDAC 
and  at  CCA.  At  CCA  the  buffer  space  is  reduced  because  of  a 
Very  Distant  Host  ( VDH ) interface.  At  SDAC  the  problem  is  the 
large  number  of  multi-packet  messages  that  terminate  in  that  PIP. 
Corrections  for  these  problems  are  in  progress  and  will  be 
implemented  before  the  problems  become  a restriction  on  the 
seismic  traffic. 

It  was  not  possible  to  perform  experiments  over  communication 
satellite  links  so  the  effects  of  the  satellite  hops  could  only 
be  examined  analytically. 

Task  II 

The  effort  u^-der  this  task  was  devoted  to  design  of 
routine  monitoring  procedures  to  identify  marginal  operation  of 
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the  communication  system.  As  a Host  the  CCP  does  not  have 
access  to  data  concerning  the  IMP  subnet  performance.  The  delay 
timer  statistics  for  the  time-marked  input  data  and  the  output 
queue  lengths  can  provide  a great  deal  of  diagnostic  information 
about  network  performance.  Procedures  for  monitoring  and  use 
of  these  indicators  have  been  described. 

Task  III 

In  order  to  use  existing  seismic  stations  with  a minimum 
of  interference  at  the  station,  the  system  design  uses  ^the 
concept  of  a mini-Host  on  the  AHPA  Network  to  interface  with 
the  seismic  station  controllers  in  a manner  compatible  with 
the  station  controller  design.  Under  this  task  the  specifica- 
tions for  the  mini-Host,  called  a Seismic  Private  Line  Interface 
(SPLI),  have  been  prepared.  The  specifications  include  the  Host 
protocol  descriptions  for  communication  with  the  CCP. 

Task  IV 

The  study  performed  under  task  I indicated  that  the 
buffer  sizes  and  Host  protocols  specified  for  the  seismic  data 
network  were  adequate  for  circuits  comparable  to  those  that  have 
been  used  for  VDH  and  RJE  connections  In  previous  AHPA  Network 
experiments  and  applications.  However,  the  quality  of  the  local 
communication  circuits  in  the  vicinity  of  the  seismic  stations 
could  conceivably  be  so  poor  that  network  performance  would 
be  unsatisfactory.  Therefore,  under  task  IV  we  have  examined 
possible  design  changes  that  could  be  used  to  compensate  for 
unreliable  communication  circuits.  Additional  buffering  through- 
out the  system  and  the  implied  increased  delay  times  for  the 
fixed  delay  paths  would  be  tne  most  effective  modification  but 
would  be  quite  expensive. 

Finally,  planned  modifications  to  the  ARPA  Network  that 
have  been  influenced  to  some  extent  by  the  studies  performed 
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under  this  contract  w l 1 be  implemented  later  thin  year . We 
recommend  that  the  results  or  tanks  II  and  III  and  the  protocols 
be  reviewed  when  their*  changes  are  made.  Improvement  In  the 
s e 1 s m i c n e t w o r k p e r f o r ma n c e a n d the  p e r f o r m a n c o mo n 1 1 o r 1 n g 
capability  may  be  achievable  as  a result  of  the  modifications. 
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INTRODUCTION 


Background 

As  part  of  the  effort  under  the  Vela  program  for  improving 
the  capability  to  detect  and  identify  underground  nuclear 
explosions  by  seismic  means,  ARPA  in  supporting  the  development 
jf  a worldwide  networK  of  seismic  stations.  Some  of  these 
stations  will  communicate  on-line  with  the  processing  center 
at  SDAC  ana  with  a large  archival  storage  system  at  CCA. 

Re commend at ions  for  the  design  of  the  communication,  processing, 
and  storage  system  were  prepared  under  previous  studies.  Under 
the  present  contract  we  have  been  performing  various  engineering 
studies  in  support  ef  the  implementation  of  this  seismic  data 
collection  network,  coneentrat ing  in  particular  on  the  communication 
sunsy=  em.  The  communication  within  the  seismic  network  will 
use  b oh  leased  line  and  ARPA  network  paths.  We  have  been  most 
e o r: c t : e d w 1 1 h t h e ]. a 1 1 e r * . 

Objecti ves 

Pour  tasks  were  assigned  in  the  contract  work  statement. 

Task  I involve  i the  maintenance  and  verification  of  the  Host/Host 
level  protocols  ter  the  ARPA  network  paths  in  the  seismic  network. 
Task  II  Involved  design  of  procedures  for  operational  monitoring 
of  the  performance  of  the  seismic  subnet  in  the  ARPA  Network. 

Task  TIT  required  the  generation  of  specifications  for  the 
Seismic  Private  L • ne  Interface  (SPLI)  which  will  act  as  a Host 
to  interface  seismic  station  processors  with  the  ARPA  Network. 

The  final  task  consisted  of  special  studies  to  be  assigned 
during  the  contract  performance  period.  As  a result  of  concern 
about  the  quality  of  communication  facilities  available  for 
connecting  to  the  remote  seismic  stations,  the  effort  under 
task  IV  consisted  essentially  of  preparing  a backup  or  contingency 
design  which  considered  such  steps  as  more  buffer  capability  at 
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the  stations  and  more  sophisticated  Host/Host  protocols  on  these* 
remote  links. 


In  the  body 
discussed  in  more 
cations,  and  an  1 
traffic  and  the  A 
for  each  f these 


of  this  report , each  of  th*' n,o  tasks  is 
ietail.  Copies  of  tiie  protocols,  SPLI  specif i- 
nterim  report  on  the  interact 'on  of  the  seismic 
ffA  network  that  provided  a basis  for  the  analysi 
fasK::  are  enclosed  as  anpendi  .es  to  this  report. 
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TASK  I:  PROTOCOL  MAINTENANCE  AND  VERIFICATION 

Introduction 

The  major  objective  of  this  task  was  to  verify  the  adequacy 
of  the  planned  protocols  for  use  of  the  ARPA  Network  to  achieve 
the  necessary  reliability  and  throughput.  A secondary  objective 
was  coordinating  and  maintaining  updated  versions  of  the  special 
Host/Host  protocols. 

Protocol  Maintenance 

At  the  beginning  of  the  contract  period  it  was  felt  that 
the  protocols  were  close  to  being  frozen.  However,  as  the 
implementation  of  required  computer  programs  proceeded,  modifica- 
tions to  facilitate  the  implementation  under  the  available 
operating  systems  and  to  accommodate  changes  in  the  archival 
file  formats  were  requested.  This  task  then  involved  achieving 
agreement  on  those  changes  that  seemed  most  valuable  and  least 
disruptive  to  other  parts  of  the  system.  As  a result  of 
these  perturbations,  the  protocol  specifications  were  not  finalized 
until  quite  late  in  the  performance  period.  The  final  versions 
of  the  following  protocols  are  included  as  Appendix  A to  this 
document:  1)  NORSAR/CCP,  2)  DP/CCP,  3)  SIP/CCP,  A)  36O/AA/CCP. 

The  protocols  for  ILPA/CCP  and  KSRS/CCP  communication  are 
described  in  the  SPLI  specifications  in  Appendix  C. 

Protocol  Verification 

The  communications  protocols  for  the  seismic  data  subnet- 
work were  verified  by  a combination  of  analysis  and  experiment. 

The  throughput  capacity  of  the  ARPA  computer  network  was 
measured  in  a series  of  experiments  last  autumn  with  support  of 
the  Network  Control  Center.  It  was  found  that  the  maximum 
data  rate  over  a standard  50  kilobit/second  (Kbs)  line  is 
about  37  Kbs.  (The  remaining  13  Kbs  are  used  by  the  ARPA 
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Network  eormunicat ions  protocols  and  routing  messages.)  As 
the  number  of  hop'  in  a network  path  increases,  particularly 
with  a satellite  hop,  the  maximum  data  throughput  rate  will 
begin  to  decrease  because  the  round-trip  delay  increases  and 
because  the  network  protocols  allow  only  eight  messages  to  je 
in  transit  between  two  Hosts  at  any  one  time.  This  phenomenon 
begins  to  occur  in  paths  of  about  12-15  conventional  hops  long. 

(It  is  not  expected  to  bother  the  seismic  data  transmission 
since  round  trip  delays  are  expected  to  be  the  order  of  3-^ 
seconds  including  a satellite  hop  and  the  data  rate  is  only 
cne  5 kilobit  data  message/second  from  each  site.) 

A detailed  analysis  of  the  data  flow  paths  was  performed 
and  transmitted  to  the  sponsor  as  BBN  Report  2995 , "Use  of  the 
•*«RPA  Network  by  the  Seismic  Data  Collection  Network".  It  is 
included  in  this  report  as  Appendix  B. 

Basically  the  report  indicated  several  areas  where  the 
ARPA  Network  w^uld  have  to  be  expanded  to  accommodate  the  large 
amount  of  anticipated  seismic  data.  These  areas  were  the  re- 
assembly buffer  space  at  the  CCA  and  SDAC  network  connections 
and  the  capacity  of  the  lines  in  the  Northeast  Corridor  between 
CCA  and  SDAC . 

The  report  also  indicated  that  the  siesmic  data  would 
experience  a nominal  delay  of  at  at  3 seconds  between  the  SPLI 
and  the  CCP.  No  experiments  could  De  performed  to  substantiate 
this  analysis  since  the  proposed  satellite  link  was  not  available. 
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TASK  II:  OPERATION  VERIFICATION  AND  MONITORING 

Introduct i on 

Based  on  the  conclusions  of  BBN  Report  2995,  monitoring 
several  characteristics  cf  the  seismic  data  subnetwork  will 
provide  an  adequate  measure  of  system  performance.  The  time 
delay  statistics  from  the  various  sites  to  the  CCP  will  give 
an  indication  of  the  current  state  of  the  communications  path 
as  well  as  providing  information  about  changes  in  path  character- 
istics due  to  seismic  subnetwork  or  ARPA  Network  changes. 
Monitoring  the  amount  of  reassembly  buffer  space  available  at 
the  SDAC  IMP  will  provide  information  on  the  availability  of 
this  scarce  resource  as  more  a,.d  more  of  the  seismic  subnetwork 
comes  online.  Finally,  an  indication  of  the  available  throughput 
from  the  CCP  to  the  mass  store  is  given  by  monitoring  the  length 
of  the  CCP’s  output  buffer.  Of  these  measures,  the  CCP  has 
a capability  for*  operator  examination  of  the  delays,  there  is 
no  direct  method  of  determining  the  reassembly  buffer  space 
use  in  the  IMP,  and  the  interrogation  of  the  SIP  output 
queue  by  the  CCP  could  easily  be  implemented.  Use  of  these 
measures  for  monitoring  the  seismic  network  performance  is 
discussed  in  more  detail  below. 

Potential  Problem  Areas 

Data  transmission  problems,  if  encountered,  are  expected 
to  fall  into  three  categories.  First,  trouble  may  occur  due  to 
a hardware  or  software  problem  in  the  part  of  the  communication 
link  where  CD AC  has  responsibility  (the  CCP,  the  SPLI,  the 
station  controller,  etc.).  In  general,  these  problems  will 
cause  a cessation  of  data  being  received  from  the  affected  sites. 

Second,  a software  or  hardware  failure  in  the  IMP  subnet- 
wor  : could  cause  trouble  (if  the  failure  influences  the  route 
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take:,  by  the  seismic  data).  The  problem  may  take  the  form  of 
increased  delays  or*  may  result  in  a cessation  of  data  from  one 
or  more  sites.  In  either  case,  t lie  responsibility  lies  with 
the  AHPA  Network  Control  Center*. 

Finally,  situations  may  arise  where  the  AKPA  Network  is 
performing  nominally,  but  demand  for  a limited  network  resource 
has  increased  to  the  point  where  data  transmission  rates  begin 
to  suffer.  A problem  such  as  this  could  occur  if  the  amount  of 
non-seismic  traffic  competing  with  the  seismic  data  for  line 
bandwidth  over  a certain  path  increases  to  the  point  where  the 
demand  for  throughput  exceeds  the  line  bandwidth.  Another  ex- 
ample would  be  when  the  seismic  network  grows  to  the  extent  that 
the  scarcity  of  message  reassembly  buffers  at  the  CCP  IMP 
severely  limits  throughput. 

Other  problems  may  occur  because  of  the  current  specifica- 
tions for  a Host- IMP  interface.  If  a Host  begins  transmitting 
a multi-packet  message  and  the  network  cannot  allocate  reassembly 
space,  the  IMP  will  stop  accepting  the  bitstream  from  the  Host 
and  the  interface  will  become  blocked.  In  this  situation,  the 
Host  cannot  communicate  with  anyone  else  or  the  network  until 
reassembly  space  is  allocated  ana  the  IMP  starts  accepting  the 
bitstream  from  the  Host  again.  This  is  an  example  of  the  current 
so-called  ’’blocking”  interface.  (The  possibility  of  implement- 
ing a non-blocking  interface  is  • iscussed  later.) 

Monitoring  and  Diagnostic  Procedures 

In  diagnosing  a problem  which  hampers  the  operation  of 
the  seismic  subnetwork,  information  to  help  localize  the  source 
of  the  problem  and  to  suggest  its  possible  causes  may  be  gained 
by  observing  which  sites  are  affected  by  the  problem.  For 
example,  if  data  from  only  a single  site  were  bein^  lost  or 
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experiencing  long  delays,  one  would  first  suspect  the  parts  of 
the  transmission  path  for  data  from  that  site  which  did  not 
overlap  that  of  data  from  any  other  site.  In  general,  this  would 
be  the  parts  of  the  transmission  path  starting  with  the  affected 
site  and  working  towards  the  CCP. 

Conversely,  if  several  sites  begin  experiencing  difficulties 
simultaneously,  one  would  suspect  problems  on  the  part  of  the 
transmission  path  in  common  to  the  tvro  data  streams.  If  all  the 
sites  begin  experiencing  difficulties  simultaneously,  one  would 
expect  the  problem  to  be  at  or  near  the  CC?-end  of  the  trans- 
mission path. 

The  ARPA  Network  IMPs  can  provide  snapshots  and  packet 
tracing  as  two  debugging  tools,  but  th^se  facilities  are  not 
accessible  to  an  ordinary  Host.  Consequently , the  constant 
monitoring  which  must  be  done  from  the  CCP  cannot  take  advantage 
of  these  tools.  Since  data  coming  into  the  CCP  has  een  time- 
stamped  at  the  SPLI,  it  would  be  possible  to  incorporate  a 
program  for  measuring  time  statistics  (e.g.,  a short-term  maximum 
delay  and  a long-term  average  for  each  site)  directly  into  the 
CCP.  By  examining  the  pattern  of  which  sites  are  sending  data, 
which  are  acknowledging  Hello  messages,  and  which  ones  have 
increasing  delays,  a rough  diagnosis  of  any  problem  is  possible 
without  NCC  assistance. 

For  example,  figure  1 shows  a possible  decision  flo w 
chart  for  the  situation  where  the  CCP  is  still  getting  data  from 
a site,  but  the  delay  statistics  (short-term,  long-term,  or 
both)  indicate  that  a marginal  situation  has  been  encountered. 
Similarly,  figure  2 shows  a possible  decision  flow  chart  for  the 
situation  where  data  from  a site  (or  sites)  stops  abruptly  for 
an  extended  period  (one  minute  or  greater).. 
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Short-Term  or  Long-Term  Delay 
Statistics  Exceed  Some  Empirically 
Derived  Threshold 


Short-term 
delays  keep 
growing  with 
frequent 
losses  of  data. 


Doth  long-term 
and  short-term 
statistics  are 
gradually 
increasing . 

i 

Suspect  heavy 
traffic  on 
common  path- 
way from  af- 
fected sites 
to  CCP. 


All  SHes 

i 

Suspect  lack 
of  reassembly 
buffers  at 
CCP  IMP. 


Not  all  sites 

i 

Other  through- 
put problem 
affecting  only 
certain  sites 
(e.g.  heavy 
competing 
traffic 
saturating 
some  link). 


Short-term  sta- 
tistics increase 
sharply,  then 
level  off.  Long- 
term statistics 
increase  slowly. 


New  equilibrium 
reached  at  a 
longer  delay. 
Suspect  rerout- 
ing or  other 
topological 
changes  in 
network. 


Figure  1.  Decision  Flow  Chart  For 
Delay  Statistics  Outside  Empirically 
Determined  N<  ^mal  Range 
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Figure  2.  Decision  Flow  Chart  for  a Cessation  of  Data 
(Blocking  Interface) 
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In  detail,  figure  i incorporates  the  following;  scenario:*. 

If  traffic  were  heavy  on  the  AHPA  Network,  it  would  be  competing 
with  the  seismic  data  for  network  resources,  most  notably  line 
bandwidth  and  processor  bandwidth.  This  will  cause  delays  to 
increase  for  the  seismic  data  as  the  amount  of  competing  traffic 
i .ureases  because  the  seismic  data  will  spend  more  time  wait! rig 
in  queues,  for  the  resources  to  become  available.  Consequently, 
if  the  CCP  operator  were  observing  delay  statistics,  re  would 
see  the  short-term  and  long-term  averages  fluctuate  slowly  as 
a function  of  other  traffic. 

If  it  is  observed  that  the  short-term  av^rag^  keeps 
growing  (that  is,  the  data  keeps  falling  farther  and  farther 
behind  real  rime)  and  frequent  losses  of  data  occur,  then  it  is 
likely  that  the  throughput  capacity  necessary  to  transmit  the 
seismic  data  to  the  CCP  is  not  currently  available.  This  could 
happen  if  a line  became  saturated  with  traffic,  for  example, 
or  could  not  support  its  usual  throughput  because  of  a temporary 
t ec h.n leal  d i f f i c u 1 r y . 

if  this  kind  of  behavior  is  observed  for  data  arriving  from 
all  sites,  then  one  should  strongly  suspect  that  there  is  inad- 
equate throughput  in  the*  seismic  subnetwork  bucause  of  the 
scarcity  of  message  reassembly  buffers  at  the  CCP  IMP.  Since 
reassembly  space  must  be  reserved  before  a (multi-packet)  data 
message  can  be  sent,  a scarcity  of  buffer  space  will  cause  the 
data  from  all  sites  to  become  congested  ("backed-up"). 

If  there  is  a failure  of  one  of  the  components  of  the  ARPA 
Network,  the  network  will  be  able  to  re-route  messages  around 
the  problem  in  most  cases.  If  a seismic  data  stream  should  have 
to  undergo  such  a re-routing,  it  would  be  reflected  in  the  delay 
statistics  in  the  following  manner.  First,  the  short-term 
delay  would  increase  rapidly  during  the  short  period  while  the 
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new  route  in  being  established.  (Actually,  there  is  a brier 
cessation  of  data  which  may  oi*  may  not  last  long  enough  to 
exceed  t no  SPLI  buffer  capacity.)  Then,  the  short-term  average 
will  level  off  at  new  equilibrium.  The  long-term  average  will 
correspondingly  grow  to  a new  equilibrium  when  the  new  route  is 
established.  Again,  this  phenomenon  may  be  observed  in  data 
■ eceived  from  one  or  several  sites  depending  on  how  many  data 
- -reams  had  to  be  re-routeu  because  of  the  failure. 

A data  stream  may  also  cease  abruptly.  In  this  case  the 
CCP  begins  to  send  "Hello”  messages  to  the  "silent"  SPLI.  If 
the  SPLI  is  running,  it  will  reply  with  an  " I-heard-you"  (THY) 
message  which  indicates  to.  the  CCP  that  the  SPLI  is  functioning. 

If  the  SPLI  is  not  transmitting  data  because  the  site  station 
controller  is  not  functioning,  the  CCP  will  receive  the  IHY 
ana  tr.e  CCP  operator  can  conclude  that  the  problem  is  upstream 
of  the  SPLI.  If  the  SPLI  is  not  running  or  if  the  SPLI  IMP 
is  isolated  from  the  CCP  IMP,  the  TMr  subnetwork  will  return 
the  appropriate  reply  in  response  to  the  CCP's  attempt  to  send 
a "Hello”  to  the  SPLI. 

If  a data  message  is  lost  within  the  ARPA  Network,  it  will 
take  between  30  and  6 0 seconds  for  the  network  protocols  to  re- 
solve this  incomplete  transmission.  Consequently,  it  will  appear 
to  the  CCP  that  the  data  stream  has  ceased  suddenly.  During  this 
period  of  time,  the  SPLT-IMP  interface  is  blocked  (the  possibility 
of  a non-blocking  interface  is  discussed  later).  Consequently, 
the  IHY  message  from  the  SPLI  Is  no^  allowed  into  the  network 
until  the  incomplete  transmission  is  resolved  and  the  data 
messages  begin  to  be  transmitted  again.  From  the  CCP’s  point 
of  view,  it  will  look  as  if  there  has  been  no  response  to  its 
"Hello"  for  some  time,  until  the  interface  becomes  unblocked. 
However,  it  is  possible  for  the  CCP  to  know  that  the  "Hello" 
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was  received  by  the  SPLI , because  it  will  receive  the  RKNM 
(Request  for  Next  Message)  from  the  IMP  subnetwork  acknowledging 
the  successful  delivery  of  the  ’’Hello”  message . 

rf  no  message  is  received  by  the  CCP,  the  implication  is 
that  its  ’’Hello”  message  got  lost  by  the  network.  In  this 
unlikely  case,  subsequent  "Hello"  messages  will  be  held  at 
the  SPLI  IMP  until  the  incomplete  transmission  caused  by  the 
missing  "Hello"  is  resolved  (30-60  seconds).  This  is  done  because 
the  IMP  network  maintains  the  order  of  transmission  for  messages 
between  a Host  pair. 

One  final  possibility  is  that  the  COP  IMP  is  not  functioning 
properly.  In  this  case  data  from  all  sites  would  cease  abruptly 
and  the  CCP  would  not  be  able  to  send  its  "Hello"  messages. 

Note  that  figure  2 uses  the  response  from  the  SPLI  (I- 
heard-you)  or  the  IMP  subnetwork  to  determine  the  situation. 
Consequently,  to  fully  utilize  this  decision  tree,  the  CCP 
program  would  have  to  be  augmented  to  communicate  these  responses 
to  the  CCP  operator. 

Long  Term  Performance  Monitoring 

Monitoring  the  CCP  output  queue  length  and  keeping  statis- 
tics about  its  growth  can  be  done  by  augmenting  the  CCP  program. 
This  would  provide  the  CCP  operator  v/ith  a direct  measure  of  the 
ARPA  Network’s  ability  to  carry  the  seismic  data  from  the  CCP  to 
the  SIP  at  the  required  throughput  rate. 

In  addition  to  the  statistics  taken  at  the  CCP,  it  is 
possible  for  the  CCP  operator  to  ask  .the  NCC  operator  to  use 
the  snapshot  facility  on  the  source  (SPLI)  or  destination  (CCP) 

IMP  if  trouble  is  suspected  there.  Snapshots  of  intermediate 
jMPs  can  also  be  taken  to  determine  routing  and  store-and-forward 
queue  lengths. 
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M o n t h 1 y statistics  wo u 1 d a i a o b o u a o f u 1 in  monitoring  l ho 
growth,  of  the  seismic  data  subnetwork  and  the  effect  of  changes 
and  growth  in  the  ARPA  .’Jet work  It. a- if.  Snapshots  of  the  IMPs 
along  the  seismic  data  transmission  path  taken  once  a month  would 
provide  information  as  to  changes  in  the  .nominal  routing  and 
store-and-forward  queue  lengths.  With  the  cooperation  of  the 
network  Control  Center,  packets  may  be  traced  as  they  are 
processed  by  the  IMP  subnetwork  and  statistics  recorded  as  to 
the  length  of  time  spent  in  the  various  processing  tasks  in 
each  IMP  as  well  as  the  send  and  receive  times  for  each  packet. 

In  addition,  excerpts  from  the  l.'CC  monthly  statistics 
could  be  used  to  monitor  long-term  effects  of  AP.PA  Network 
changes  on  se’smic  data  transmission.  These  statistics  include 
line  usage,  i umber  of  packets  between  111?  pairs,  and  line  and 
IMP  down  times.  The  daily  and  hourly  statistics  might  be 
helpful  in  a postmortem  evaluation  of  some  situations. 

Do  lay  statistics  can  best  be  calculated  and  stored  at 
CD  AC  since  the  seismic  '"Data  will  be  time- stamped  and  the  delay 
measured  at  the  COP.  In  general,  the  ARP A Network  cannot 
conveniently  measure  delay  statistics  on  a regular  basis. 

For  example,  a statistic  which  might  be  valuable  in 
studying  the  distribution  of  competing  traffic  is  the  delay  as 
a function  of  time-of-day.  This  statistic  would  indicate  if 
operation  of  the  seismic  data  collection  is  nominal,  marginal 
only  during  "rush"  hours,  or  always  marginal  due  to  the  amount 
of  non-seismic  traffic. 

Recommendation  for  Future  Effort 

The  ARPA  Network  is  continually  growing,  and  new  features 
are  continually  being  added  to  the  message-handling  software 
in  the  IMPs.  Several  changes  planned  for  the  end  of  this  year* 


hSee  ARPA  Network  Information  Center  Memo  II NIC  32655,  June  h,  1975 ■ 
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have  been  influenced  by  this  study  and  could  improve  seismic 
data  throughput  and  the  capability  of  the  CCP  to  diagnose 
marginal  situations.  The  first  change  is  the  inclusion  of  a 
handling  type  (currently  only  regular  or  priority  is  used) 
which  would  allow  Hosts  to  communicate  on  several  logical  channels. 
If  one  channel  becomes  blocked  due  to  an  incomplete  transmission, 
the  Hosts  (SPLI  and  COP)  could  continue  communicating  on  another 
logical  channel  until  the  Network  resolves  the  incomplete 
transmission  (which  usually  takes  30-60  seconds). 

The  second  change  Is  the  implementation  of  a non-blocking 
Host-IMP  interface.  This  would  be  an  aid  to  CCP-generated 
experiments.  For  example,  if  the  CCP  were  receiving  data  from 
a 'site  more  slowly  than  usual,  it  could  initiate  a Hello  message 
to  that  site  on  a different  logical  channel.  If  it  received  a 
time-stamped  I-neard-you  reply  and  thc  CCP  noted  that  its 
delay  was  nominal,  one  could  conclude  that  lack  of  message 
reassembly  space  at  the  CCP- IMP  was  causing  the  slowdown.  This 
is  because  the  essential  difference  in  the  netv/ork’s  handling 
of  single  and  multi-packet  messages  is  the  reservation  of 
reassembly  space  at  the  destination  IMP  for  multi-packet  messages. 
Currently,  the  I-neard-you  reply  would  not  be  sent  out  until 
after  the  multi-packet  message  because  it  would  be  blocked  at 
the  source  Host-IMP  interface. 

Also,  the  implementation  of  a non-blocking  Host-IMP 
interface  along  with  the  ability  cf  the  CCP  to  send  priority 
Hellos  and  receive  time-stamped  priority  I-heard-you  messages 
fr,om  the  SPLI  would  provide  a means  of  measuring  delay  due  to 
store-and-forward  queue  length  in  the  network.  This  would  be 
done  by  comparing  priority  T-heard-you  delays  with  regular 
T-heard-you  delays.  (The  priority  messages  are  placed  at  the 
front  of  the  queues  whenever  possible.)  Delay  due  to  queue 
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length  is  an  indication  of  the  amount  of  network  traffic  competing 
with  the  seismic  data  fnp  the  network  resources. 

We  therefore  recommend  a review  of  the  seismic  subnet 
protocols  and  performance  monitoring  procedures  after  these 
AHPA  Network  changes  have  been  incorporated. 
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TASK  III : SPLI  SPECIFICATIONS 


Requ i remen  t 

in  order  to  minimis#  the  coot  of  implementing  the  seismic 
da ip  collection  network,  sites  which  have  been  or  will  be 
implemented  to  serve  other  requirements  will  b'1  integrated  into 
t/ne  network.  Thus  the  data  collection  network  function  is  often 
a secondary  mission  for  the  station.  Tt  is,  therefore,  important 
that  connection  to  the  network  should  introduce  a minimum  of 
redesign  and/or  operational  complexity.  Several  of  the 
stations  were  designed  to  transmit  on-line  data  from  the  station 
controllers  over  leased  lines.  Rather  than  modifying  the  station 
controllers  to  implement  Host  protocols  when  using  the  ARPA 
Network  It  was  decided  to  introduce  a minicomputer  Most  which 
would  acc-pt  data  from  the  station  controller  in  the  previously 
defined  format.  The  minicomputer  would  then  reformat  the  data 
and  provide*  Host  protocol  for  transmission  over  the  ARPA 
Network.  To  the  station  controller  the  SPLI  appears  as  a modem 
or.  a leased  line  and  to  tne  ARPA  Network  the  SPLI  appears  as  a 
Host  computer . 

I u order  not  to  constrain  the  location  of  the  SPLI,  the 
interface  between  the  SPLI  and  its  ARPA  Network  IMP  uses  the 
Very  Distant  Host  ( VDH ; design. 

under  the  initial  seismic  network  configuration,  two  forms 
of  th  SPLI  were  required,  one  for  ILPA  and  one  for  the  KSRS 
class  stations. 

Under  this  task  we  were  required  to  prepare  specifications 
to  be  used  .in  procuring  the  SPLIs.  Since  the  SPLI  must  implement 
the  special  Host/Host  protocols  for  communicating  with  the  COP, 
the  preparation  of  SPLf  specifications  was  closely  related  to 
4 he  effort  under  task  I and  the  communication  protocols  are 
defined  in  the  SPLT  specifications.  The  resulting  SPLI  specifi- 
cations are  included  as  Appendix  C of  this  report. 
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TASK  IV:  SPECIAL  STUDIES 

Background  and  Definition 

Because  the  seismic  data  collection  network  will  be  the 
secondary  mission  for  some  of  the  seismic  stations,  the  system 
design  attempts  to  minimize  the  effect  of  the  network  on  station 
operation  and  maintenance.  In  this  design  the  problem  of 
adapting  to  stat ion-to-station  peculiarities  is  handled  in  the 
CCP;  the  CCP  is  a general-purpose  computer  located  near  adequate 
program  support  and  its  use  does  not  put  any  burden  on  station 
personnel . 

The  design  objective  was  therefore  to  maintain  highly 
reliable  communication  with  the  on-line  stations  with  minimum 
bandwidth  local  communications  and  minimum  equipment  (for 
minimum  maintenance  and  operation)  at  the  station.  This 
objective  requires  a tradeoff  between  buffer  size  and  program 
complexity  (required  by  sophisticated  Host/Host  protocol)  vs. 
minimum  equipment  and  bandwidth  in  the  field.  Based  on  the 
analysis  described  in  Appendix  B and  on  previous  ARPA  Network 
experience  a buffer  size  of  8 to  10  seconds  was  chosen.  It  was 
decided  not  to  attempt  Host  level  retransmission,  and  the 
special  Host/Host  protocol  has  been  kept  to  a minimum. 

This  compromise  design  caused  some  concern  and,  under 
task  IV,  we  were  asked  essentially  to  recommend  contingency 
plans  in  case  the  resulting  reliability  was  unsatisfactory. 

Analysi s 

For  the  analysis,  the  communication  with  a remote  station 
is  considered  in  four  segments  with  significantly  different 
characteristics.  These  segments  are  1)  station  controller  to 
SPLI,  2)  SPLI  to  IMP,  3)  IMP  subnet  including  the  satellite  hop, 
and  4)  destination  IMP  to  CCP.  These  segments  are  discussed  in 
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more  detail  below. 

The  communications  circuit  between  the  station  controller 
and  the  SPLI  does  not  have  any  error  detection  or  correction 
capability.  Consequently,  we  recommend  that  the  SPLI  be  co- 
located with  the  station  controller  to  avoid  reliance  on  possibly 
marginal  communication  circuitry  for  this  unprotected  path. 
Without  extensive  changes  in  the  station  controller  ther^  is  no 
way  to  improve  reliability  over  this  path. 

The  link  between  the  SPLI  and  the  SPLI  IMP  will  be  a Very 
Distant  Host  (VDH)  interface.  A VDH  interface  does  provide  for 
checksumming  and  retransmission  of  data  with  detected  errors, 
so  that  high  probability  of  correct  data  is  possible.  One 
problem  which  may  occur  results  when  the  probability  of  a packet 
(1024  bits  of  data)  being  sent  correctly  the  first  time  begins 
to  decrease.  This  causes  the  number  of  retransmissions  to  in- 
crease and  consequently  the  effective  bandwidth  of  the  communi- 
cations line  to  decrease.  If  this  effective  bandwidth  decreases 
below  the  required  throughput  rate  of  the  seismic  data  (5066 
bits/second  for  K3RS  and  1342  for  ILPA),  data  losses  will  occur. 
The  solution  to  this  problem  is  to  provide  a higher  throughput 
by  increasing  the  circuit  bandwidth  (use  of  a higher  bandwidth 
line  or  several  lines  in  parallel). 

Once  the  data  is  within  the  ARPA  Network  it  is  reliably 
transmitted  to  the  destination  CCP  IMP.  The  ARPA  Network,  of 
course,  is  designed  to  permit  rapid  and  reliable  digital  commu- 
nications between  Host  computers.  Consequen  ;ly , responsibility 
for  error  checking,  retransmission,  discarding  of  duplicates, 
acknowledgments,  and  determination  of  the  fastest  route  through 
the  network  rests  entirely  with  the  IMP  subnetwork.  Problems 
which  may  arise  are  expecoed  to  fall  into  one  of  two  categories. 


17 


Report  No.  3109 


Bolt  Beranek  and  Newman  Inc. 


The  first  category  consists  of  hardware  or  software  failures 
in  the  IMP  subnetwork.  In  general,  the  IMP  subnetwork  will  be 
able  to  respond  to  such  failures  by  rerouting  the  seismic  data 
(as  well  as  other  traffic)  around  the  failure.  At  the  CCP,  this 
will  result  in  longer  delays  for  a few  data  messages  until  the 
new  path  is  established. 

If  the  delay  exceeds  the  buffering  capacity,  data  will  be 
lost.  Obviously,  increasing  the  buffer  size  will  decrease  the 
susceptibility  of  the  seismic  network  to  this  kind  of  problem. 
During  the  transient,  it  is  possible  that  a packet  can  get  lost, 
and  this  will  result  in  an  incomplete  transmission  for  the 
message  containing  that  .jacket.  It  wi]l  take  the  IMP  subnetwork 
between  30  and  60  seconds  to  resolve  this  problem  in  its  message 
accounting  and  to  inform  the  source  ..ost  of  an  incomplete  trans- 
mission; consequently,  to  recover  from  an  incomplete  transmission 
it  is  necessary  to  have  upwards  of  60  seconds  of  buffer  space 
in  addition  to  giving  the  SPLI  the  capability  to  retransmit  the 
message . 

Another  situation  for  the  CCP  operator  to  be  aware  of  is 
scheduled  outages  of  key  IMPs  for  preventive  maintenance  and 
new  releases  of  IMP  software.  A backup  plan  to  cover  these 
contingencies  might  consist  of  local  recording  of  seismic  data 
to  provide  a large  amount  of  effective  ”buf fering"  during  the 
outage . 

Note  that  larger  buffering  capacity  at  the  SPLI  means  that 
the  ,,catch-up-time,,  (the  time  needed  to  completely  empty  the 
ouffer  while  it  is  being  filled  with  new  data)  will  be  pro- 
portionately increased.  If  it  is  desirable  to  reduce  the 
catch-up-time,  it  can  be  done  only  by  increasing  the  bandwidth 
of  the  lines  connecting  the  SPLI  to  its  IMP. 
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The  second  category  consists  of  situations  where  i.hc  IMP 
subnetwork  is  performing  perfectly,  but  the  seismic  data  cannot 
be  transmitted  quickly  enough  because  of  network  resource 
limitations.  An  example  of  such  a situation  is  when  the  through- 
put demands  placed  on  the  network  by  the  seismic  and  regular 
traffic  exceed  the  capacity  of  the  network.  In  this  case, 
possible  contingencies  include  increasing  buffer  capabilities 
if  the  conditions  are  transient  or  reducing  the  amount  of  seismic 
data  being  sent  (sacrificing  some  data  so  that  ^he  rest  of  it 
gets  through)  if  the  conditions  are  mo  *e  lor.g-iiveo. 

For  problems  in  category  two,  the  best  long-term  approach 
is  to  pinpoint  the  area  of  congestion  to  determine  precisely 
what  resource  (bandwidth  on  some  line,  message  reassembly  buffers, 
etc.)  is  scarce.  Then,  as  needs  dictate,  the  ARPA  Network  can 
"grow"  to  handle  the  expanding  demands  for  throughout  f; om  the 
seismic  n e t w o r k . 

Finally,  it  could  be  argued  that  a Host-level  positive 
acknowledgment  scheme  to  allow  retransmission  of  a message  that 
does  not  checksum  correctly  at  the  CCP  should  be  implemented  to 
protect  data  bits  from  Incorrect  transmission  at  the  destination 
Host-IMP  interface.  (The  source  interface  contains  error 
detection  and  ret ransmi ssi on  capability  since  it  is  a VDU  inter- 
face.) However,  such  a protocol  would  duplicate  many  of  the 
features  of  the  IMP  subnetwork.  The  only  new  feature  it  would 
allow  is  retransmi ssi on  of  messages  which  were  altered  at  the 
IMP-CCP  interface,  and  there  is  no  reason  to  expect  these  errors 
to  be  frequent  enough  to  compromise  the  data  quality  . Such  a 
change  to  the  CCP-SPLI  protocol  must  also  allow  for  several 
messages  "in  flight".  If  it  does  not,  then  the  maximum  through- 
put possible  with  the  protocol  would  be  smaller  than  the  input 
data  rate.  Increased  buffering  and  a retransmission  protocol 
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would  have  to  be  incorporated  in  the  SPLI  so  that  messages  with 
detected  errors  could  be  retransmitted. 

Conclusions 

As  a result  of  our  study  of  contingencies  for  the  seismiv 
network,  we  have  reached  the  following  conclusions.  First,  the 
incorporation  of  additional  memory  (buffer  space)  at  the  SPLIs 
and  CCP  would  allow  the  seismic  network  to  survive  all  transient 
conditions  likely  to  be  experienced  on  the  ARPA  Network. 

Conditions  which  could  not  be  survived  are  insufficient  through- 
put due  to  a scarcity  of  network  resources  for  an  extended  period 
(several  minutes)  and  isolation  of  an  SPLI  from  the  CCP  due  to 
a hardware  problem  for  an  extended  period. 

Secondly,  if  the  amount  of  memory  is  increased  at  an  SPLI, 
it  is  strongly  recommended  that  the  bandwidth  of  the  communica- 
tions circuits  from  the  SPLI  to  its  IMP  be  increased  in  order  to 
increase  the  ’’catch-up"  rate.  This  would  allow  a more  rapid 
recovery  after  a transient  slowing  or  cessation  of  data  and 
therefore  decrease  the  time  it  would  take  for  the  SPLI  to  be  able 
to  survive  another  transient  without  loss  of  data. 

Third,  in  order  to  survive  an  incomplete  transmission  with- 
out loss  of  data,  the  SPLI  buffering  capability  would  have  to  be 
increased  to  about  60-75  seconds  and  the  protocol  changed  so  that 
the  SPLI  can  retransmit  the  incomplete  message.  The  CCP  buffering 
capability  would  have  to  be  increased  accordingly. 

Finally,  the  cost  of  such  changes  would  be  the  cost  and 
installation  of  the  additional  memory  and  the  cost  of  the  protocol 
changes  in  the  CCP  and  SPLIs.  Another  important  point  to  bear 
in  mind  is  that  the  rixed  delay  in  the  seismic  data  seen  by  the 
recipients  of  the  data  from  the  CCP  would  be  increased 
commensurably . 


20 


Report  No.  3109 


Bolt  Beranek  and  Newman  Inc. 


CONCLUSIONS  AND  RECOMMENDATIONS 

As  indicated  in  BBN  Report  i?99r3  (included  in  Appendix  B), 
the  design  of  the  seismic  communication  path  using  the  ARPA 
.vei.work  is  basically  sound.  In  that  report  and  in  the  studies 
conducted  since  that  report  was  issued,  a few  potential  problem 
areas  have  been  discovered  and  are  being  corrected. 

Some  network  resources  will  have  to  be  expanded  as  the 
seismic  traffic  load  grows,  but  this  form  of  expansion  is  routine. 
Last  January,  the  ARPA  Network  had  55  nodes.  Currently  (July  1975) 
it  has  AO  nodes,  and  the  changes  necessary  to  allow  more  IMPs 
than  the  previous  limit  of  63  are  being  made.  In  adoition, 
major  topology  changes  are  planned  which  will  increase  the 
number  of  eoast-to-coast  lines  and  East  Coast  Corridor  lines. 
i;J°  reBu]t  Wl]]  bo  that  the  longest  possible  network  path  will 
be  reduced  to  nine  hops.  Such  changes  are  proof  that  the  ARPA 
Network's  flexibility  allows  it  to  grow  to  meet  users-  needs  in 
an  organised  fashion. 

A potential  problem  is  the  ability  of  the  seismic  data  to 
surviv  transients  in  the  network.  The  most  difficult  transient 
to  predict  is  a re-routing  transient.  The  length  of  time  needed 
to  cnange  routes  may  or  may  not  cause  data  to  be  lost,  depending 
on  the  exact  circumstances.  Our  analysis  indicates  tnat  the 
amount  of  buffering  currently  planned  for  the  SPLI  is  sufficient 
for  most  circumstances;  however,  if  re-routing  transients 
repeatedly  cause  data  losses,  additional  memory  at  the  SPLIs 
and  the  CCP  can  provide  the  increased  buffering  needed  to 
survive  these  re-routing  transients. 

Because  the  ARPA  Network  is  currently  undergoing  a number 
of  topological  and  protocol  Improvements,  our  final  recommendation 
is  that  the  impact  of  these  changes  on  the  seismic  network  be 
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explored  when  they  are  implemented.  In  this  way  the  changes, 
particularly  the  non-blocking  interface  and  the  new  handling 
types,  may  be  studied  both  analytically  and  experimentally  to 
see  what  changes  could  be  made  to  the  CCP  and  the  SPLIs  to 
improve  performance,  reliability,  and  on-line  monitoring  functions. 
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From:  H.  Briscoe 

To:  Lt.  M.  Marcus,  VSC 

Subject:  Communication  Protocol  between  the  CCP  and  the  SIP. 

1 . Introduction 
1 . 1 Background 

A worldwide  seismic  data  collection  network  including 
approximately  6 on-line  array  stations  is  being  implemented 
under  ARPA  sponsorship.  The  objecti/e  of  the  network  is  to 
provide  data  f^g  research  in  nuclear  test  detection  and 
identification.  A network  event  list  will  be  prepared 
within  a couple  of  days  of  real-time  using  on-line  event 
detection  and  computer  aided  event  analysis  at  the  Seismic 
Data  Analysis  Center  (SDAC).  The  data  collected  by  the 
network  will  be  filed  in  a large  digital  Mass  Store  facility 
at  CCA. 

The  communication  network  used  to  interconnect  the 
primary  seismic  stations,  the  SDAC  processing  facility,  and 
the  Mass  Store  will  include  a mix  of  dedicated  leased 
circuits  and  ARPA  Network  circuits.  The  overall  design  of 
the  seismic  data  network  is  described  in  [1].  The  overall 
design  of  the  ARPA  Network  is  described  in  [2]  and  [3]. 
Protocols  for  interaction  between  the  communication  subnet 
and  the  "Host"  installations  are  described  in  [4]. 

This  document  describes  the  formats  and  protocols  for 
communication  between  the  CCP  and  the  Seismic  Input 
Processor  (SIP).  Communications  between  the  CCP  and  the  SIP 
use  the  ARPA  Network. 

1.2  System  Configuration  and  Restraints 

The  CCP  will  essentially  be  interfaced  as  a Host  to 
both  the  TIP  and  the  IMP  but  only  one  CCP  interface  v:ill  be 
in  use  at  any  time.  This  machine  may,  thus,  have  two 
possible  Host  addresses. 

A second  novel  aspect  of  the  seismic  data 
communications  use  of  the  ARPA  Network  is  the  real-time 
fixed  delay  constraint.  In  particular,  it  is  required  that 
the  communications  links  operate  so  that  the  data  will  be 
delivered  to  some  destinations  with  constant  delay  behind 
real-time,  i.e.  the  network  should  appear  to  be  an  "ideal 
(error  free)  delay  line"  to  that  destination. 

The  communication  protocol  described  in  this  document 
builds  upon  the  Host-IMP  Protocol  [4]  and  is  at  the 
Host-to-Host  level  although  it  is  not  the  standard  Host-Host 
Protocol  described  in  [5].  The  Host-IMP  Protocol  [4]  is 
included  in  this  specification  by  reference. 
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1.3  Organization  of  this  Document 

In  section  2 the  content  and  format  of  the  data  being 
exchanged  over  the  communication  system  are  specified. 

These  data  must  be  embedded  in  messages  that  include 
routing  and  error  control  information.  The  message  formats 
are  described  in  section  3. 

Finally,  the  operating  protocols  or  rules  for  the 
exchange  of  data  and  control  messages  are  specified  in 
section  4 . 

2.0  Data  Formats 

2.1  Data  Formats  from  the  CCP  to  the  SIP 

Four  forms  of  data  will  be  sent  from  the  CCP  to  the 
SIP.  One  form  of  data  is  the  file  structure  parameters 
which  describe  the  seismic  data  message  field  sizes.  The 
second  form  of  data  is  actual  seismic  sensor  data.  The  CCP 
groups  the  sensor  data  into  frames  and  then  subdivides  each 
frame  into  messages,  each  containing  data  from  two  source 
stations,  for  transmission  to  the  SIP.  The  third  form  of 
data  is  sensor  status  change  data  for  sensors  whose  data  is 
being  transmitted.  The  fourth  form  of  data  is  operator 
messages  to  be  typed  on  the  SIP  operator  console. 

The  format  of  the  file  structure  data  is  as  follows: 

Field  1:  bytes  0 to  1 : N = number  of  sites. 

Field  2:  bytes  2 to  13:  First  site  parameters  coded  as 
follows : 

Bytes  2 to  5:  Site  name  plus  1 byte  padding. 

Bytes  6 and  7:  Number  of  16  bit  words  of  SP  status 

data . 

Bytes  8 and  9:  Number  of  16  bit  words  of  SP  data. 

Bytes  10  and  11:  Number  of  16  bit  words  of  LP  status 

data . 

Bytes  12  and  13:  Number  of  16  bit  words  of  LP  data. 

Fields  3 to  N+1 : Nth  site  parameters  coded  as  for  the 
first  site. 

The  format  for  the  seismic  data  blocks  containing  data 
from  two  stations  for  one  second  is  as  follows: 

Field  1:  bytes  0 and  1:  number  of  words  in  the  first  site 
data  block  including  fields  2 to  5 inclusive. 

Field  2:  bytes  2 to  9:  Time-of-day: 


'LIS' 
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16  BCD  characters  as  follows: 
char.  use 

1 0 


2 and  3 

two  digits  of 

the  year 

4,5,  and  6 

three  digits  < 

d f day  number 

7,8 

two  digits  of 

hours 

9,10 

two  digits  of 

minutes 

11,12 

two  digits  of 

seconds 

13,14 

two  zeros  for 

hundredths  of  seconds 

15,16 

padding-zeros 

Field  3*.  bytes  10  to  12:  site  identity: 

3 ASCII  characters  of  site  name 

Field  4:  byte  13:  site  status 

Field  5:  seismic  data  including 

subfield  1 : SP  status  padded  to  a word  boundary 
subfield  2:  SP  data:  10  or  20  samples  (depending 
on  sample  rate)  of  each  SP  channel.  Each 
sample  is  a 16  bit  .fixed  point  number. 

Samples  are  ordered  in  frames  of  1/10  or  1/20 
second  each  containing  one  sample  from  each 
seismometer . 

subfield  3:  LP  status  padded  to  a word  boundary 

subfield  4:  LP  data:  1 sample  from  eaeh  LP 

seismometer.  Each  sample  is  a 16  bit  rain  ranged 
number . 


Fields  6 to  10:  same  as  fields  1 to  5 but  for  the  second 

site  data. 

The  format  of  the  status  change  data  is  as  follows: 

Field  1:  bytes  0 to  5:  Time-of-day; 

Coded  as  the  first  12  characters  of  time  in  the 
seismic  data. 

Field  2:  bytes  6 and  7:  Number  of  channels  with  changed 

status . 

Fields  3 through  N(number  of  channels):  Channel  id  and 
status: 

14  bytes  coded  as  follows: 

3 bytes  ASCII  characters  for  site  id 
If  site  id  =000,  complete  status  of 
entire  network  will  follow  this  message. 

1 byte  ASCII  character  for  channel  type, 
i = individual  seismometer 
s = subarray  beam 
b = array  beam 
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a = adaptive  beams 
e = all  channels  from  this  site. 

2 bytes  ASCII  characters  for  sample  rate  in 
samples  per  second. 

4 ^tes.*SCI1  characters  for  channel  id  within 
tne  site. 

i >*te  AfCI1  character  for  gain  code(H  or  L). 

I tfyte  of  sensor  component. 

1 byte  of  sensor  status  bits. 

1 byte  o: fset  location  cf  sensor  in  site  data. 


The  format  for  the  orerator 
follows: 


data  is  as 


Field  1:  bytes  0 and  1:  Character  count  = N. 

Field  2;  bytes  2 to  N+1  or  N+2:  Text  padded  to 

a full  v/ ora  boundary. 

2.2  Data  Formats  from  the  SIP  to  the  CCP. 

the  StatW?nf»7lS1°f'.dara/fnt  from  the  SIP  t0  the  CCP  are 
SIP  tn  tho  n 1Jed  llSt  0f  data  that  has  teen  passed  from  the 

«.p  f »« type,.  5 

The  format  of  the  list  of  filed  2_a_ta  is  as  follows: 

F1'la  ;:t?o?Sp,°dd?a|:  Ihr"  brteS  °r  *«•  •—  on. 

Field  2:  bytes  4 to  13:  File  identifier: 

xen  ASCII  character  file  name. 

Field  3:  bytes  14  to  19:  Starting  TOD  of  the  filed  data- 

taOded  same  as  field  1 of  the  status  change  data. 

Field  4:  bytes  20  to  25:  End  TOD  of  the  filed  data: 

Codinm  same  as  field  1 of  the  status  change  data. 

secti^fif"^  °f  the  aafirator  data  ^ described  in 

3.  Message  formats 
3. 1 CCP  to  SIP 

CCP  tn6  fhl6  -td6S  of  "esaa^es  that  can  be  sent  from  the 
7P  then  oIP  ace  the  Structure  Check  messages  (type  7' 

the  Seismic  Data  message  (type  0),the  Status  Message  (type 
8),  the  Acknowledge  message  (type  1).  and  the  Operate- 
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messape  ( type  5 ) . 


The  messape  format  for  Structure  Check  messapes  is  as 
follows : 


Field  1:  bytes  0 to  3:  Host-to-IMP  leader 

(see  [4]) 

bit  1 ; Priority  bit  = 0 
bits  2-8:  zeros 

bits  9-10:  destination  Host  number 

bits  11-16:  destination  IMP  number 

bits  17-28:  link  number 

bits  2h-32:  zeros 


F ield 

2: 

byte  4: 

Source 

Host  id. 

Field 

3: 

byte  5: 

messape 

type  = 7 

Field 

4: 

bytes  6 

au*  7: 

Unique  messape  id. 

Field 

b: 

File  structure 

parameter  data  (see  s 

Field 

6: 

2 byte 

checksum 

for  fields  2, 3, 4, and 

checksum  defined  as  a 16  bit  number 
computed  by  subtracting  the  arithmetic  sum  of 
the  values  of  the  words  in  the  checked  fields 
from  the  number  of  words  in  the  checked  fields 
usir.-p  two's  complement  binary  arithmetic. 


The  messape  format  for  the  Seismic  Data  messapes  is 
as  follows: 


Field  1:  bytes  0 to  3;  Host-IMP  Leader. 

(same  as  Structure  Check  messape) 

Field  2:  byte  4:  Source  Host  id. 

Field  3:  byte  5:  messape  type  = 0. 

Field  4:  bytes  6 and  7:  Unique  messape  id. 

Field  5:  Seismic  data  (see  section  2.1). 

Field  6:  2 bytes  checksum  for  fields  2,3,4,  and  5: 
Computed  as  for  Structure  Check  Messape. 

The  format  for  the  Sensor  Status  messape  is  as 
follows : 


Field 


1:  bytes  0 to  3:  Host-IMP  leader: 

(same  as  for  Structure  Check  Message) 
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Field  2:  byte  4:  Source  Host  id. 

Field  3*  byte  5:  message  type  = 8. 

Field  4:  bytes  6 and  7:  Unique  message  id. 

Field  5:  sensor  status  (see  section  2. i). 

Field  6:  checksum  on  fields  2,3,4  and  5 : 

Computed  as  for  the  Structure  Check  Message. 

The  format  for  the  Acknowledge  message  is  as  follows: 

Field  1:  bytes  0 to  3:  Host-IMP  leader: 

same  coding  as  for  Structure  Check  Message. 

Field  2:  byte  4:  Source  Host  id. 

Field  3**  byte  5:  Message  type  = 1. 

Field  4:  bytes  6 and  7:  Unique  id  of  message  being 
acknowledged . 

Field  5:  bytes  8 and  9:  Checksum  on  fields  2,3  and  4: 

Computed  as  for  the  Structure  Check  Message. 

The  format  of  the  Operator  message  is  as  follows: 

Field  1:  bytes  0 to  3:  Host-to-IMP  leader: 

Coding  same  as  for  Structure  Check  message. 

Field  2:  byte  4:  Source  Host  id. 

Field  3:  byte  5:  Message  type  = 5. 

Field  4:  bytes  6 and  7:  Unique  message  id. 

Field  5:  Operator  message  (see  section  2.1). 

Field  6:  Two  byte  checksum  on  fields  2,3,4  and  5: 

Computed  as  for  Structure  Check  message, 

3.2  SIP  to  CCP 

The  four  types  of  messages  sent  from  the  SIP  to  the  CCP 
include  Acknowledge  for  messages  received  from  the  CCP 
(type  1),  Host-Going-Down  (type  4),  Data  Filed  message  (type 
9),  and  Operator  message  (type  S). 

The  format  of  Acknowledge  messages  is  described  in 
section  3.1. 
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The  format  of  the  Host -Going;- Down  messages  is  as 
f ol lows : 


Field  1:  bytes  0 to  3:  Host-IMP  leader: 

Same  format  as  for  Structure  Check  messages 
( see  section  3 • 1 ) - 


Field 

2: 

bytes  4 and  5: 

message  type  = 4 

The 

format  of  the 

Data  Filed  message  is 

as  follows: 

Field 

1 : 

bytes  0 to  3: 

Host-to-IMP  leader: 

Same  coding  as  for 

Structure  Check  message. 

Field 

2: 

byte  4:  Source 

Host  id . 

Field 

3: 

byte  5:  Message  type  = 9. 

Field 

4: 

bytes  6 and  7: 

Unique  message  id. 

Field 

5: 

bytes  8 to  33- 

Data  filed  list  (see 

section  2.2). 

Field 

6: 

bytes  34  and  35 

: Checksum  on  fields 

2,3,4  and  5. 

Computed  same  as  for  Structure  Check  message. 


Hie  format  of  the  Operator  message  is  desribed  in 
section  3*1* 

4.0  Operating  Procedures 

In  normal  operation,  the  CCP  will  send  3 seismic  data 
messages  to  the  SIP  each  second.  Each  message  contains  one 
second  cf  data  from  two  seismic  stations. 

Whenever  the  status  of  a sensor  whose  data  is  being 
sent  to  the  SIP  is  changed  (manually  by  the  CCP  operator  or 
automatically),  a sensor  Status  Message  is  sent  from  the  CCP 
to  the  SIP  for  that  sensor.  If  the  status  of  all  sensors  at 
a given  site  change  at  the  same  time,  a special  case  of  the 
Status  Change  message  will  be  sent 

Approximately  once  each  hour  a Structure  Check  message 
will  be  sent  from  the  CCP  to  the  SIP.  If  the  f le  structure 
parameters  for  any  site  are  inconsistent  with  the  current 
file  format,  the  SIP  will  stop  filing  data  from  that  site 
and  will  notify  the  operating  personnel. 

At  midnight  G.M.T.,  at  startup  after  any  interruption 
of  communication  between  the  CCP  and  the  SIP,  or  by  operator 
command,  a Structure  Check  message  followed  by  a special 
Status  Chance  message  (indicating  full  network  status  will 
follow)  followed  by  the  full  status  of  the  entire  network 
will  be  sent  from  the  CCP  to  the  SIP. 


After  recieving  and  acknowledging  a Host-Going-Down 
message  from  the  SIP,  or  anytime  the  CCP  determines  that 
communication  with  the  SIP  has  been  interrupted  the  CCP  will 
send  Structure  Check  messages  to  the  SIP  periodically. 
Receipt  of  an  acknowledge  for  one  of  these  messages  will 
indicate  that  the  system  has  returned  to  normal. 

In  the  other  direction  the  SIP  will  send  a Data  Filed 
message  to  the  CCP  for  all  data  successfully  passed  to  the 
Datacomputer . 

Operator  messages  will  be  sent  in  either  direction 
under  command  of  the  sending  operator. 

If  the  SIP  is  being  taken  off-line  for  maintenance  or 
other  predictable  reason,  a Host-Going-Down  message  will  be 
sent  to  the  CCP  or  an  equivalent  message  will  be  entered  by 
the  CCP  operator. 

All  messages  except  Acknowledge  messages  exchanged 
between  the  CCP  and  the  SIP  will  be  acknowledged  at  the 
Host-to-Host  level  if  received  with  correct  checksum. 

All  data  messages  will  be  saved  in  the  source  Host 
until  the  Acknowledge  for  that  data  is  received.  The 
source  Host  will  retransmit  unacknowledged  messages 
approximately  every  four  seconds  until  the  buffer  is  deleted. 
If  any  Host  is  buffering  ten  seconds  of  unacknowledged 
messages  the  oldest  buffers  may  be  reused  for  new  data  and 
the  operator  will  be  notified. 

Since  the  CCP  may  be  on  one  of  two  Host  connections  to 
the  network,  the  SIP  will  send  messages  to  the  Host  address 
from  which  it  received  the  latest  Seismic  Data  message  with 
a kood  checksum. 
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From:  H.  Briscoe 

To:  Lt.  M.  Marcus,  VSC 

Subject:  Communication  Protocol  between  NORSAR  and  SDAC. 

1 . Introduction 

1 . 1 Background 

A worldwide  seismic  data  collection  network  includi..  - 
approximately  6 on-line  array  stations  is  being  implemented 
under  ARPA  sponsorship.  The  objective  of  the  network  is  to 
provide  data  for  research  in  nuclear  test  detection  and 
identification.  A network  event  list  will  be  prepared  w:_  ..in 
a couple  of  days  of  real-time  using  on-line  event  detect-  r. 
and  computer  aided  event  analysis  at  the  Seismic  Data 
Analysis  Center  (SDAC).  The  data  collecteo  by  the  network 
will  be  filed  in  a large  digital  Mass  Store  facility  at  CCA. 

The  communication  network  used  to  interconnect  the 
primary  seismic  stations,  the  SDAC  processing  facility, 
and  the  Mass  Store  will  include  a mix  of  dedicated  leasee 
circuits  and  ARPA  Network  circuits.  The  overall  design  of  fne 
seismic  data  network  is  described  in  [1].  The  overall  desi 
of  the  ARPA  Network  is  described  in  [2]  and  [3]. 

Protocols  for  interaction  between  the  communication  subnet  and 
the  "Host"  installations  are  described  in  [4]. 

This  document  describes  the  formats  and  protocols  fer 
communication  with  one  of  the  primary  sites,  the  Norwegian 
Seismic  Array  (NORSAR).  Communication  with  NORSAR  uses 
the  ARPA  Network.  The  NORSAR  station  communication  is 
unique  in  that  a)  the  station  not  only  sends  data  but  alic 
receives  data,  and  b)  the  data  exchanged  includes  processed 
information.  This  document,  therefore,  describes  both  the 
communication  between  NORSAR  and  the  CCP  and  the  exchange  of 
processed  data  between  the  CCP  and  the  360/40A  Detection 
Processor  (DP)  at  SDAC. 

1.2  System  Configuration  and  Restraints 

The  NORSAR  Detection  Processor  (DP)  will  be  interfaced  to 
the  NORSAR  Terminal  Interface  Processor  (TIP)  as  a "Host".  The 
NORSAR  TIP,  the  SDAC  TIP,  and  the  SDAC  IMP  are  each  nodes  in  the 
ARPA  Network.  The  path  between  the  NORSAR  TIP  and  the  SDAC  TIP 
and  IMP  will  include  one  hop  via  a communication  satellite.  The 
SDAC  DP  and  the  CCP  will  essentially  be  interfaced  as  Hosts  to  both 
the  TIP  and  the  IMP  but  only  one  CCP  and  one  DP  interface 
will  be  in  use  at  any  time.  These  machines  may,  thus,  have  two 
possible  Host  addresses. 

A second  novel  aspect  of  the  seismic  data  communications 
use  of  the  ARPA  Network  is  the  real-time  fixed  delay  constraint. 

In  particular,  it  is  required  that  the  communications  links 
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operate  so  that  the  data  will  be  delivered  to  some  destinations  with 
constant  delay  behind  real-time,  i.e.  the  network  should  appear 
to  be  an  ’’ideal  (error  free)  delay  line”  to  that  destination. 

The  communication  protocol  described  in  this  document 
builds  upon  the  Host-IMP  Protocol  [4]  and  is  at  the  Host-to-Host 
level  although  it  is  not  the  standard  Host-Host  Protocol  described 
in  [r)].  In  spite  of  the  fact  that  there  is  considerable  variation 
among  the  array  sites  with  respect  to  data  format,  rate  and  type 
of  ARPANET  access,  much  of  the  protocol  described  below  is 
similar  to  the  protocol  for  sites  other  than  NORSAR. 

1.3  Organization  of  this  Document 

In  section  2 the  content  and  format  of  the  seismic 
data  being  exchanged  over  the  communication  system  are  specified. 

These  data  must  be  embedded  in  messages  that  include  routing 
and  error  control  information.  The  message  formats  are 
described  in  section  3. 

Finally  the  operating  protocols  or  rules  for  the  exchange  of 
data  and  control  messages  are  specified  in  section  4. 

2.  Data  Formats 

2.1  CCP  to  and  from  NORSAR. 

Each  second  one  frame  of  data  will  be  assembled  at  the 
CCP  for  transmission  to  NORSAR  and  one  frame  of  data  will  be 
assembled  at  NORSAR  for  transmission  to  the  CCP. 

2.1.1  CCP  to  NORSAR 

Each  f^ame  of  data  from  the  CCP  to  NORSAR  will  have  the 
following  g ta: 

Field  1:  bytes  0 to  3:  control  characters: 

character  sequence  SYN-SYN-DLE-STX . 

Field  2:  bytes  4 to  17:  LASA  Signal  Arrival  Queue  file  entry: 

data  from  field  1 of  the  last  frame  of  processed  data 
from  the  DP  (see  section  2.2) 

Field  3:  bytes  18  to  21:  LASA  Time-of-Day  (TOD): 

using  ISRSPS  format 

Field  4:  bytes  22  to  28:  LASA  LP  Status  and  Repeat  bits: 

first  30  bits  assigned  to  30  components  of  LP  data  in  the 
same  order  as  LDC  to  CCP  message.  Bits  set  to  1 when 
corresponding  sensor  is  down.  Remainder  of  bytes  22  to  27 
are  zeros.  Bit  5 of  byte  28  is  on  if  no  LASA  LP  data 
are  present.  Byte  28  bit  6 is  on  if  any  polycode  errors 
were  detected  in  transmission  from  LDC  to  CCP.  Byte  28 
bit  7 is  on  if  any  LP  data  within  the  frame  are 
repeated  data. 
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Field  5: 

Field  6: 
Field  7: 


Field  8: 


Field  9: 
Field  10a 


Bvte 

0 

1 

2~5 
6-10 
1 1 


bytes  29  to  130:  LASA  LP  data: 

LASA  long  period  data  values  ordered  by  component  and 
subarray  as  they  are  transmitted  From  LDC  to  CCP. 
bytes  131  to  134:  ALFA  Time-of-day  (TOD): 

coded  same  as  LASA  TOD  Field  3. 

bytes  135  to  142:  ALPA  LP  status  and  repeat  indicator: 

ALPA  LP  sensor  status  arranged  by  site,  3 bits  per 
site . 


For 


each 

Bit 

1 

2 

3 

142 
any 


on  when  sensor  down 


subarray : 

Sensor 
LV 
LN 
L c 

bit  5 on  iF  no  ALPA  data  present.  Byte  142  bit  6 
polycode  errors  were  present  in  transmission  oF 
Byte  142  bit  7 on  iF  any  LP  data 
data.  Unused  bits  are  zero. 


Byte 
on  iF 

data  From  ALPA  to  CCP. 
in  the  Frame  arc  repeat 


bytes  143  to  256:  ALPA 

Data  values  ordered  by 
total  oF  57  values  in  16 
bytes  257  to  28 2:  zeros 

: bytes  283  to  294:  Text 

twelve  bytes  oF  operator 
to  NDPC.  Text  is  broken 
lonr  and  messages  Formatted 
Description 

Start  oF  message  characters  - must  equal  X 

Count  oF  NDPC  to  3AAC  messages  required  to 

complete  the  message 

Time  oF  day,  in  ISRSPS  Format 

Message  identification  (S70CA)  or  (N700*) 

Message  control  Field 


LP  data: 

site  and  component  For  a 
bit  pain  ranged  Format. 

From  CC?  operator: 
nessape  From  the  CCP  operator 
into  messapes  up  to  128  bytes 
as  Follows. 


FF' 


Bits 

0 

1 

2-7 


1 2 — N 


Set  to  one  to  indicate  last 
message  or  sinrle  nessape 
Set  to  zero  to  not  ring  alarm 
Spare  - encoded  as  zeros. 
Message  text 


bell 


Field  10b:  bytes  283  to  291:  SP  request  data: 

This  is  a special  Format  oF  operator  message  that  may 
replace  Field  10a. 

Format  For  this  Field  is  as  Follows: 

Byte  Description 

0 Data  Reauest  Nessape  IdentiFi'  set  equal 

to  X'FE' 

1 Number  oF  short  period  channels  requested 

(0-3) 
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2 Number  of  subarray  beam/array  beam  values 

requested  (0-3) 

3-8  Channel/Beam  numbers  (2  bytes  each) 

Field  11:  bytes  20 5 to  298:  Control  characters: 

character  sequence  DLE,ETB,0,0 
Field  12:  byte  299:  spare-coded  as  zeros: 

2.1.2  NORSAR  to  CCP . 


Each  frame  from  NORSAR  to  the  CCP  will 
following  data: 


Field  1 


Field  2; 


Field  3 


Field  4 


bytes  0 to  3:  Control  Characters 
character  sequence  SYN,  SYN,  DLE, 
bytes  9 to  9:  Time  of  day: 

12  BCD  characters  as  follows: 


have  the 


STY 


character 

1 

2&3 

4, 8, *6 
7,8 
9,  10 
11,12 

bytes  1C  to  27: 


use 
0 

two  digits  of  the  year 
three  digit  of  day  number 
two  digits  of  hours 
two  digits  of  minutes 
two  digits  of  seconds 
NORSAR  detection  log  reduction  groups: 


processed  data  to  be  transmitted  to  the  SDAC  DP  in  the  next 
frame  (see  section  2.2) 

bytes  28  to  37:  LP  status  and  repeat  indicators: 

This  field  contains  NORSAR  LP  sensor  status  arranged 
continuously  by  subarray  3 bits  per  subarray.  For 
each  subarray: 

Bit  Sensor 

1 LV 

2 LN  set  when  sensor  is  down 


3 LE 

By to  36,  bits  2 through  7,  and  byte  37,  bits  0 through  5,  are 
spare,  encoded  zero. 

Byte  37,  bits  6 and  7 are  repeat  indicators  which  are  set 
whenever  any  SP  or  LP  data  within  the  record  is  repeated  data. 


When  set  (1)  the  bits  indicate  the  following: 
bit  6 - SP  data  is  repeated  (at  least  .5  second  of 
data  is  repeated) 

bit  7 - LP  data  is  repeated  (at  least  1 value  is  repeated). 


Field  5:  bytes  38  to  169:  NORSAR  LP  data: 

This  field  contains  long  period  data  values  ordered 
by  component  and  subarray  for  a total  of  66  long 
period  values.  Each  value  is  in  16  bit  gain  ranged  form. 
The  components  are  ordered  LV,  LN,  and  LE.  The  22  long 
period  values  (one  for  each  subarray)  for  component  LV 
are  recorded  in  the  field  first,  followed  by  the  22 
for  LN,  followed  by  the  22  for  LE. 
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Field  6 


T 


Field  7: 


Field  8: 
Field  9: 


bytes  170  to  17b:  NORSAR  SP  channel  identification: 

Three  two-byte  entries  containing  the  type  and  channel 
or  beam  number  of  the  short  period  data  in  field  7. 

The  data  may  be  short  period  channel,  subarray 


beam  or  array  beam  data,  as  selected  by 


operator.  Each  entry 
bits  Content 

0-3  Type  of 

4-15  Channel 

If  no  short  period 
this  field  will  be 


has  the  following 


the  SDAC 
format : 


data  identifier 
or  beam  number  of  data 
data  has  been  requested  by  SDAC, 
all  zeros. 


bytes  176  to  235:  NORSAR  SP  data: 

This  field  contains  one  second's  worth  of  short  period 
data  f rom  each  of  the  channels  and/or  beams  identified 
in  Field  6;  the  data  for  each  channel  and  beam  is 
recorded  at  a 10  Hz  rate.  The  field  is  divided  into 
ten  subfields,  each  containing  a decisecond's  worth 
of  data.  Each  subfield  is  six  bytes  in  length  and  contains 
one  two-byte  data  value  for  each  channel  and/or  beam 
identified  in  Field  6.  If  only  one  or  two  channels  and/or 
beams  are  being  transmitted,  the  latter  two-byte 
entries  of  each  subfield  will  contain  zeros  (the  latter 
two  it  one  channel,  the  latter  one  if  two  channels). 

If  no  channels  and/or  beams  are  being  transmitted,  this 
entire  field  will  contain  all  one  bits, 
bytes  236  to  283:  NORSAR  off-line  results: 

processed  data  to  be  transmitted  to  SDAC  DP  in  the 
next  frame  (see  seotion  2.2). 
bytes  284  to  2Q1:  Operator  text 

Operator  messages  from  NORSAR  to 

Maximum  messarp  length  of  128  bytes.  A twelve  byte 
header  is  added  and  the  resulting  message  is  broken 
into  8 byte  groups  for  transmission  in  successive 
frames  . 

Message  format  is  as  follows: 


messages : 

the  CCP  operator. 


Bvte 

0 

1 

2-5 

6-10 

1 1 


Description 

Start  of  message  characters  - must 
equal  X'FF' 

Count  of  NDPC  to  SDAC  messages  required  to 
complete  the  message 
Time-of-day,  in  ISRSPS  format 
Message  identification  (N700A)  or 
( N 7 3 7 A ) 

Message 
Bits. 

0 


control  field 


12-n 


1 

2 

3-7 

Messare 


Set  to  one  to  indicate  last 

message  or  single  message 

Set  to  zero  to  not  ring  alarm  bell 

Set  to  one  to  indicate  NDPC  "A"  system 

Spare  - encoded  as  zeros 

text 


A-  1 5 


ito.il  illililiJ 


Field 

10: 

Bytes  292 

to 

298: 

control 

characters : 

character 

sequence 

DLE , ETB 

, 0,0 

Field 

1 1 : 

bytes  296 

to 

299: 

spares 

coded  as  zeros. 

2.2 

CCP 

to  and  from 

DP 

Whenever  processed  data  is  available  in  the  DP, 
the  data  will  be  assembled  in  the  DP  for  transmission  to 
the  CCP  to  be  forwarded  to  NORSAR.  Each  second  the  processed 
data  received  from  NORSAR  during  the  previous  second  will  be 
assembled  in  the  CCP  and  passed  to  the  DP. 

2.2.1  DP  to  CCP 


Each  frame  of  data  from  the  DP  to  the  CCP  will  have  the 
following  data: 

Field  1:  bytes  0 to  5:  Time-of-day: 

12  BCD  characters  as  follows: 
char.  use 


Field  2 : 


1 0 

2&3  twc  digits  of  the  year 

4,S,&6  three  digit  of  day  number 

7,8  two  digits  of  hours 

9,10  two  dipits  of  minutes 

11,12  two  digits  of  seconds 

bvtes  6 to  19:  LASA  Signal  Arrival  Queue  File 

Entry:  data  for  field  2 of  a CCP  to  NORSAR 

nessape  (see  section  2.1) 


2.2.2  CCP  tr  DP 


Each  frame  of  processed  data  from  the  CCP  to  the  SDAC  DP 
will  have  the  following  data: 

Field  1:  bytes  0 to  5:  time-of-the-day : as  in  field  1 

above 

Field  2:  bytes  6 to  23:  NORSAR  detection  log  reduction 

groups : 

data  from  field  3 of  the  last  NORSAR  to  CCP  message. 
Field  3:  bytes  24  to  71:  NORSAR  off-line  results: 

data  from  field  8 of  the  last  NORSAR  to  CCP  message. 
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3.  Message  Formats 

3.1  CCP/NORSAR 

The  only  messages  exchanged  between  the  CCP  and  NORSAR 
are  data  messages  as  follows: 

Field  1:  bytes  0 to  3:  Host-to-IMP  leader 

(see  [4]) 

bit  1 : Priority  bit  = 0 

bits  2-8:  zeros 

bits  9-10:  destination  Host  number 

bits  11-i8:  destination  IMP  number 

bits  17-28:  link  number 

bits  29-32:  zeros 

Field  2:  bytes  4 and  5 message  type: 

0 for  data  from  NORSAR  to  CCP.  11  for  data  from  CCP 
to  NORSAR 

Field  3:  bytes  6 to  305:  Data: 

As  described  in  section  2.1 

Field  4:  bytes  306-307:  checksum  for  fields  2 and  3 = number  of 

words  in  checksum  minus  the  arithmetic  sum  of  the  word 
values  usinr  binary  two's  complement  arithmetic. 

3.2  CCP/DP 

Two  classes  of  message  are  used  between  the  CCP  and  the  DP 
for  the  exchange  of  processed  data.  A uniaue  data  message  class 
is  used  to  separate  these  messages  from  the  sensor  data  messages. 
Messages  are  acknowledged  using  the  standard  acknowledge  message. 

The  data  messages  have  the  following  format: 

Field  1 : bytes  0 to  3.  Host-to-IMP  leader 

(see  [ 4 ] ) coded  as  in  section  3." 

Field  2:  byte  4:  source  Host  id: 

Field  3-’  byte  5:  message  type  - 10 

Field  4:  bytes  6 and  7:  Unique  message  id 

Field  5:  data  field  described  in  section  2.2 

Field  6:  2 bytes;  checksum  on  fields  2, 3, L'  and  5 

(see  section  3.1  for  coding) 

The  format  of  the  standard  acknowledgment  message  is  as 
follows : 

Field  1:  bytes  0-3:  Host-to-IMP  leader  coded  as  in  section  3.1 

Field  2:  byte  4:  source  Host  id: 

Field  3:  byte  5:  message  type  =1 

Field  4:  bytes  6 to  7:  Unique  id  of  message  being  acknowledged 

Field  5:  bytes  8 and  9:  checksum  on  fields  2, 3, and  4 

(see  section  3.1  for  coding) 
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4.  Operating  Procedures 

4.1  CCP/NORSAH 

In  normal  operation  of  the  link  between  the  CCP  and  the  NORSAR, 
both  Hosts  transmit  one  data  message  each  second.  No  attempt 
will  be  made  to  retransmit  lost  or  garbled  messges.  If 
data  is  lost  it  can  be  replaced  off-line. 

The  only  complication  in  the  operatinr  procedures  is  the  result 
of  the  fact  that  the  CCP  will  have  two  network  addresses  on  different 
IMPs  and  will  use  only  one  at  a time.  The  NORSAR  DP  must,  therefore, 
monitor  the  source  address  on  incoming  data  messages  in  order 
to  determine  the  correct  address  for  the  outgoing  data. 

If  the  NORSAR  sends  a data  message  to  the  wrong  CCP  address 
and  the  addressed  Host  interface  is  looped  for  testing,  the  IMP 
subnet  will  cause  the  message  to  be  sent  back  to  NORSAR  as  a 
message  from  the  erroneous  CCP  address.  The  NORSAR  program  must 
be  prepared  to  ignore  any  type  0 messages  it  receives. 

4.2  CCP/DP 

The  exchange  of  processed  data  between  the  CCP  and  the  DP 
at  SDAC  will  use  a positive  acknowledgment  procedure  in 
both  directions. 

Whenever  the  CCP  has  processed  data  from  NORSAR  available 
it  will  attempt  to  send  a processed  data  message  to  the  DP. 

All  messages  transmitted  to  the  DP  will  be  saved  in  the  CCP 
until  an  acknowledge  message  for  that  data  message  is  received 
or  the  message  is  at  least  ten  seconds  old.  Unacknowledged 
messages  will  be  retransmi t t ed  approximately  every  four  seconds 
until  the  buffer  is  overwritten.  When  a message  is  over  ten 
seconds  old  the  Host  may  delete  the  space  and  reuse  the  buffer 
space.  The  operator  will  be  notified  whenever  unacknowledged 
messages  are  deleted. 

Each  time  the  CCP  receives  a processed  data  message  from  the  DP 
with  a correct  checksum  an  acknowledge  message  for  that  data  will 
be  sent  to  the  DP. 

Whenever  processed  data  is  available,  the  DP  will  attempt 
to  transmit  a processed  data  message  to  the  CCP.  All  messages 
transmitted  to  the  CCP  will  be  saved  in  the  DP  until  an 
acknowledge  message  for  that  data  message  is  received.  If 
no  acknowledge  is  received  after  5 seconds  the  data  message  will  be 
retransmitted . 

Each  time  the  DP  receives  a processed  data  message  from  the  CCP 
with  a correct  checksum  an  acknowledge  message  for  that  data  will 
be  sent  to  the  CCP. 

Control  of  the  link  between  the  CCP  and  the  DP  is  described 
in  the  specification  of  the  protocol  for  communication  between 
the  CCP  and  the  DP. 
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From:  H.  Briscoe 

To:  Lt.  M.  Marcus,  VSC 

Subject:  Communication  Protocol  between  the  CCP  and  the  DP. 

1 . Introduction 
1 . 1 Background 


A worldwide  seismic  data  collection  network  including 
approximately  6 on-line  array  stations  is  beinr  implemented 
under  ARPA  sponsorship.  The  objective  of  the  network  is  to 
provide  data  for  research  in  nuclear  test  detection  and 
identification.  A network  event  list  will  be  prepared 
within  a couple  of  days  of  real-time  usinr  on-line  event 
detection  and  computer  aided  event  analysis  at  the  Seismic 
Data  Analysis  Center  (SDAC).  The  data  collected  by  the 
network  will  be  filed  in  a large  digital  M*ss  Store  facility 
at  CCA. 

The  communication  network  used  to  interconnect  the 
primary  seismic  stations,  the  SDAC  processing  facility, 
and  the  Mass  Store  will  include  a mix  of  dedicated  leased 
circuits  and  ARPA  Network  circuits.  The  overall  design  of  the 
seisnic  data  network  is  described  in  [1],  The  overall  design  of 
the  ARPA  Network  is  described  in  [2]  and  [3].  Protocols  for 
interaction  between  the  communication  subnet  and  the  "Host" 
installations  are  described  in  [4], 

This  document  describes  the  formats  and  protocols  for 
communication  of  sensor  data  between  the  CCP  and  the 
360/40  acting  as  the  Detection  Processor  (DP).  Communication 
between  the  CCP  and  the  DP  use  the  ARPA  Network.  Communication 
of  the  processed  data  1*1 elds  for  the  interaction  with  NORSAR 
also  involves  a CCP/DP  interaction  that  is  described  in  the 
document  on  communication  protocol  beteen  NORSAR  and  SDAC. 


1.2  System  Configuration  and  Restraints 

The  SDAC  DP  and  the  CCP  will  essentially  be 
interfaced  as  Hosts  to  both  the  TIP  and  the  IMP  but  only 
one  CCP  and  one  DP  interface  will  be  in  use  at  any  time. 

These  machines  nay,  thus,  have  two  possible  Host  addresses. 

A second  novel  aspect  of  the  seismic  data  communications 
use  of  the  ARPA  Network  is  the  real-time  fixed  delay  constraint. 

In  particular,  it  is  required  that  the  communications  links 
operate  so  that  the  data  will  be  delivered  to  some  destinations 
with  constant  delay  behind  real-time,  i.e.  the  network  should  appear 
to  be  an  "ideal  (error  free)  delay  line"  to  that  destination. 
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The  communication  protocol  described  in  this  document 
builds  upon  the  Host-IMP  Protocol  [4]  and  is  at  the  Host-to-Host 
level  although  it  is  not  the  standard  Host-Host  Protocol  described 
in  [5].  In  spite  of  the  fact  that  there  is  considerable  variation 
among  the  seismic  communication  paths  with  respect  to  data  format 
rate  and  type  of  ARPANET  access,  much  of  the  protocol  described 
below  is  similar  to  the  protocol  for  communication  with  the 
stations  and  for  communication  with  the  SIP. 

1.3  Organization  of  this  Document 

In  section  2 the  content  and  format  of  the  data  being 
exchanged  over  the  communication  system  are  specified. 

These  data  must  be  embedded  in  messages  that  include 
routing  and  error  control  information.  The  message  formats 
are  described  in  section  3- 

Finally  the  operating  protocols  or  rules  for  the  exchange 
of  data  and  control  messages  are  specified  in  section  44 . 

2.  Data  formats 

2.1  Data  Formats  from  the  CCP  to  the  DP 

Four  forms  of  t^ta  will  be  sent  f rom  the  CCP  to  the  DP. 

One  form  of  data  is  the  processed  data  from  NORSAR. 

Processed  data  formats  are  described  in  the  Communication 
Protocol  between  NORSAR  and  3D AC.  A second  form  of  data 
the  file  structure  parameters  which  describe  the  seismic  data 
message  field  sizes.  The  third  form  of  data  is 
actual  seismic  sensor  data.  The  CCP  groups  the  sensor  data 
into  one  second  frames  and  then  subdivides  each  frame  into 
messages  each  containing  data  from  two  source  stations  for 
transmission  to  the  DP.  The  fourth  form  of  data 
is  sensor  status  change  data  for  sensors  whose 
data  is  being  transmitted. 

The  format  of  the  file  structure  data  is  as  follows: 

Field  1:  bytes  and  1:  N=number  of  sites. 

Field  2:  bytes  2 to  13:  First  site  parameters  coded  as  follows: 

Bytes  2 to  5:  Site  name. 

Bytes  6 and  7:  Number  of  16  bit  words  of  SP  status  data. 
Bytes  8 and  9:  Number  of  16  bit  words  of  SP  data. 

Bytes  10  and  11:  Number  of  16  bit  words  of  LP  status  data. 

Bytes  12  and  13;  Number  of  16  bit  words  of  LP  data. 

Fields  3 to  N+1 : Nth  site  parameters  coded  as  for  the  first 

site . 
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The  format  for  the  seismic  data  blocks  containing  d atu  from 
two  stations  for  one  second  is  as  follows: 

Field  1:  bytes  0 and  1:  number  of  words  in  the  first  site  data 

block  including  fields  2 to  5 inclusive. 

Field  2:  bytes  2 to  9:  Time-of-day: 

16  BCD  characters  as  follows: 


char . 

use 

1 

0 

2&3 

two  dibits  of  the  year 

4,5,S6 

three  diRits  of  day  number 

7,8 

two  diRits  of  hours 

5,10 

two  digits  of  minutes 

11,12 

to  digits  of  seconds 

13,14 

two  zeros  for  hundredths  o 

15,16 

padding-zeros 

seconds 


Field  3:  bytes  10  to  12:  site  identity: 

3 ASCII  characters  of  site  name 


Field  4:  byte  13*  site  status 


Field  5:  seismic  data  including 

subfield  1 : SP  status  padded  to  a word  boundary 

subfield  2:  3P  data:  10  or  20  samples  (depending  on 

sample  rate)  of  each  SP  channel.  Each 
sample  is  a 16  bit  fixed  point  number. 

Samples  are  ordered  in  frames  of  1/10  or  1/20 
second  each  containing  one  sample  from  each 
seismometer . 


subfield  3: 


LP  status  padded  to  a word  boundary 


rub field  4: 


L?  data:  1 sample  from  each  LP  seismometer. 

Each  sample  is  a 16  bit  Rain  ranred  number. 


Fields  6 to  10:  same  as  fields  1 to  5 but  for  the  second  site  data. 


The  format  of  the  statu1  chance  data  is  as  follows: 
Field  1:  bytes  0 to  0:  Time-of-day; 

Coded  as  first  6 bytes  of  time  in  the  seismic 
data  message. 
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Field  2:  bytes  6 and  7:  Number  of  channels  with  changed  status. 


pj.3ids  3 through  N(nunber  of  channels):  Channel  id  and  status: 

14  bytes  coded  as  follows: 

3 bytes  ASCII  characters  for  site  id 

If  site  id  = 000,  complete  staatus  of  the  entire 
network  will  follow  tnis  message. 

1 oyte  ASCII  character  for  channel  type 
i = individual  seismometer 

s = subarray  beam 
b = array  beam 
a = adaptive  beam 
e = all  channels  from  this  site 

2 bytes  ASCII  characters  for  sample  rate  in  samples 
per  second. 

4 bytes  ASCII  characters  for  channel  id  within 
the  site. 

1 byte  ASCII  character  for  rain  code(H  or  L). 

1 byte  of  sensor  component. 

1 byte  of  sensor  status  bits. 

1 byte  offset  location  of  sensor  in  site  data. 

2.2  Data  Formats  from  the  DP  to  the  CCP. 

The  only  data  sent  from  the  DP  to  the  CCP  is  processed 
data  for  NGRSAR  described  in  the  Communication  Protocol 
between  NORSAR  and  SDAC  . 

3.  Message  formats 

3. 1 CCP  to  DP 

The  five  types  of  messages  that  can  be  sent  from  the  CCP  to 
the  DP  are  the  NORSAR  Processed  Data  messages  (type  10),  the  Structure 
Check  messages  (type  7),  the  Seismic  Data  message'’  (type  0), 
the  Status  Message  (type  3), and  the  Acknowledge  message  (type  1). 

Type  10  messages  are  described  in  the  Communication 
Protocol  between  NORSAR  .-.ad  SDAC. 

The  message  format  for  Structure  Check  messages  is  as  follows: 

Field  1:  bytes  0 to  3:  Kost-to-IMP  leader 

(see  [4]) 

bit  1;  Priority  bit  = 0 
bits  2-8:  zeros 

bits  9-10:  destination  Host  number 

bits  11-16:  destination  IMP  number 

bits  17-28:  link  number 

bits  29-32:  zero' 
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field  2.  byte  4 : Source  Host  id. 


Field  3 
F i e 1 ( 
Field  S 


byte  5:  message  type  ■=  7 

bytes  6 and  7:  Unique  message  id. 

file  structure  parameter  data  (see  section  2.1) 


field  6:  2 byte  checksum  for  fields  2 1 H ann  r. 

°omnkfUH  ^efined  as  a 16  bit ’number  J’ 
thePviSeSyo?UfSea?6iS-fthe  arith"etic  sum  of 
from  the  number  of  16  bifW°rda  1"  the  checked  fields 
usinK  two's  complement  binary  arithmStic^0''6'3  fields 

as  fonToh:srSS^e  for,,,at  for  the  Seismic  Data  messages  is 

field  1:  bytes  0 to  3;  Host-ItlP  Leader. 

(same  as  Structure  Check  message) 

field  2:  byte  4:  Source  Host  id. 

field  3:  byte  5:  message  type  r o. 

Field  4:  bvtes  6 and  7:  Unique  message  id. 

Field  f> : Seismic  data  (see  section  2.1). 

Field  6:  2 bytes  checksum  for  fields  2 7 4 ana  , 

Computed  as  for  Structure  Chelk  Menage! 

Th°  f0rBlat  f°r  the  status  message  is  as  follows: 

field  1:  bytes  0 to  3:  Host-IMP  leader: 

(same  as  for  Structure  Check  Message) 

field  2:  byte  4:  Source  Host  id. 

Field  3:  byte  5:  message  type  = 8. 

Field  4:  bytes  C and  7:  Unique  message  id. 

field  5.  sensor  status  (see  section  2.1). 

Field  6:  checksum  on  fields  2,3,4  and  S- 

Computed  as  for  the  Structure  Check  Message. 
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The 

format 

for  the 

Acknowledge  message 

is  as  follows: 

Field 

1 : 

bytes 

same 

0 to  3: 

codinp  as 

Host-IMP  leader: 
for  Structure  Check 

Messare  . 

Field 

2: 

byte  4 

: Source 

Host  id. 

rield 

3: 

byte 

G:  Message  type  = 1. 

field 

4: 

bytes  6 and  7: 
acknowledged . 

Unique  id  of  message  beinp 

Field 

5 : 

bytes 

8 and  9: 

Checksum  on  fields 

2 , 3 and  4 : 

Computed  as  for  the  Structure  Check  Message. 


3.2  DP  to  CCP 

The  three  types  of  messages  sent  from  the  DP  to  the 
CCP  include  processed  data  for  NORSAR  (type  10) , acknowledge 
for  messages  received  f rom  the  CCP  (type  1),  and  Hos t-Goinp-Down 
(type  4 ) . 

Processed  Data  messages  are  described  in  the 
Communication  Protocol  betecn  NORSAR  and  SDAC. 

The  format  of  Acknowledge  messares  is  described 
in  section  3.1. 

The  format  of  the  host-Goi nr-Down  messages  is  as  follows: 

Field  1:  bytes  0 to  3 • Host-XMP  leader: 

Same  format  as  for  Structure  Check  messages 
( see  section  3.1). 

Field  2:  byte  4*  may  contain  source  Host  id. 

Field  3:  byte  G:  messare  type  = 4 

4.  Operatinr  Procedures 

In  order  to  clarify  the  ranpe  of  possible  operating 
procedures  for  communication  from  the  CCP  to  the  DP,  three 
classes  of  information  available  from  the  CCP  are  defined. 

These  include  NORSAR  processed  data,  seismic  data,  and 
auxiliarv  data  consistinr  of  Status  messages  and  Structure 
Check  messages  (see  Connunicat in  Protocol  Between  the  CCP 
and  the  SIP).  Seismic  data  is  subdivided  into  Ions  period  and 
short  period  data  from  each  reporting  station.  In  normal 
operation  the  CCP  will  transmit  one  NORSAR  processed  data 
message  go  the  DP  pach  second  if  processed  data  is  beinp 
recieved  from  NORSAR.  In  normal  opreration  the  CCP  will  send  one 
frame  of  seismic  data  to  the  DP  each  second.  A frame  of 
seismic  data  may  reequire  from  one  to  three  messages  each 
containinr  data  from  up  to  two  stations.  The  seismic 
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data  transmitted  is  under  control  of  the  CCP  operator. 

He  may  designate  data  type  (long  period,  short  period,  or  both) 
to  be  transmitted  for  each  station.  Finally  the  CCP  operator 
may  command  that  auxiliary  data  will  be  transmitted  from  the 
CCP  to  the  DP  whenever  auxiliary  data  messages  are  generated. 

If  the  CCP  determines  that  the  mass  store  is  not  accepting 
data  or  if  the  CCP  operator  initiates  backup  operation 
the  CCP  will  replace  the  previously  defined  DP  seismic  and 
auxiliary  data  set  v/ith  the  data  being  transmitted  to  the  mass 
store.  The  mass  store  data  stream  is  the  same  as  long  and 
short  period  data  from  all  stations  and  auxiliary  data.  Whenever 
possible,  data  will  be  transmitted  in  chronologic  order. 

The  DP  will  send  an  acknowledge  message  to  the  CCP  for 
each  data  message  in  any  of  the  above  classes  recieved  with  a 
correct  checksum. 

In  the  other  direction  the  DP  will  send  processed  data 
messages  to  the  CCP  for  transmission  to  NORSAR  whenever 
there  are  processed  data  to  be  sent.  The  CCP  will  acknowledge 
each  processed  data  message  from  the  DP  that  is  received  with  the 
correct  checksum. 

All  of  the  data  messages  described  above  will  be  saved  in 
the  source  Host  until  either  an  acknowledge  for  the  message 
is  received  from  the  receiving  Host  or  the  message  is  ten  seconds 
or  more  old.  The  source  Host  will  retransmit  unacknowledged 
messages  approximately  every  four  seconds  until  the  buffers 
are  deleted.  When  a buffered  message  is  more  than  ten  seconds 
old,  the  source  Host  may  delete  the  message  and  reuse  the  buffer 
space.  The  operator  at  the  source  Host  will  be  notified 
whenever  unacknowledged  messages  are  deleted. 

Since  both  the  DP  and  the  CCP  may  be  on  one  of  two  Host 
connections  to  the  network,  the  correct  Host  address  for  sending 
messages  will  be  determined  as  follows: 

a)  the  DP  will  send  messages  to  the  Host  address 

from  which  it  received  the  latest  Seismic  Data  message. 

b)  the  CCP  will  send  messages  to  the  Host  address 
entered  by  the  CCP  operator. 

If  the  DP  is  being  taken  off-line  for  maintenance  or  other 
predictable  reason,  a Host-Going-Down  message  will  be  sent 
to  the  CCP  or  an  equivalent  message  will  be  entered  by 
the  CCP  operator. 
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From:  H.  Briscoe 

To:  Lt.  M.  Marcus,  VSC 

Subject:  Communication  Protocol  between  the  CCP  and  the  360/44. 

1 . Introduction 

1 . 1 Background 

A worldwide  seismic  data  collection  network  including 
approximately  6 on-line  array  stations  is  being  implemented 
under  ARPA  sponsorship.  The  objective  of  the  network  is  to 
provide  data  for  research  in  nuclear  test  detection  and 
identification.  A network  event  list  will  be  prepared 
within  a couple  of  days  of  real-time  using  on-line  event 
detection  and  computer  aided  event  analysis  at  the  Seismic 
Data  Analysis  Center  (SDAC).  The  data  collected  by  the 
network  will  be  filed  in  a large  digital  Mass  Store  facility 
at  CCA. 

The  communication  network  used  to  interconnect  the 
primary  seismic  stations,  the  SDAC  processing  facility, 
and  the  Mass  Store  will  include  a mix  of  dedicated  leased 
circuits  and  ARPA  Network  circuits.  The  overall  design  of  the 
seismic  data  network  :s  described  in  [1],  The  overall  design 
of  the  ARPA  Network  is  described  in  [2]  and  [3].  Protocols  for 
interaction  between  the  communication  subnet  and  the  "Host” 
installations  are  described  in  [ 4 ] . 

In  order  to  allow  the  entry  of  data  from  sources  not  in 
the  on-line  network  the  CCP  will  accept  data  in  VELA  block 
data  form  from  the  360/44  at  SDAC.  Data  entered  in  this  fashion 
will  be  placed  in  the  block  data  section  of  the  messages  on  the 
VELA-3  circuit.  This  document  describes  the  formats  and 
Drotocols  for  the  communication  of  block  data  from  the  360/44 
to  the  CCP. 

1.2  System  Configuration  and  Restraints 

The  CCP  will  essentially  be  interfaced  as  a Host  to  both 
the  TIP  and  the  IMP  but  only  one  CCP  interface  will  be  in  use 
at  any  time.  This  machine  may,  thus,  have  two  possible  Host 
addresses.  The  360/44  will  be  a Host  on  the  network. 

A second  novel  aspect  of  the  seismic  data  communications 
use  of  the  ARPA  Network  is  the  real-time  fixed  delay 
constraint.  In  particular,  it  is  required  that  the  communications 
links  operate  so  that  the  data  will  be  delivered  to  some  destinations 
with  constant  delay  behind  real-time,  i.e.  the  network  should  appear 
to  be  an  "ideal  (error  free)  delay  line"  to  that  destination. 

The  communication  protocol  described  in  this  document 
builds  upon  the  Host-IMP  Protocol  [4]  and  is  at  the  Hosf -to-Host 
level  although  it  is  not  the  standard  Host-Host  Protocol  described 
in  [5].  In  spite  of  the  fact  that  there  is  considerable  variation 
among  the  seismic  communication  paths  with  respect  to  data  format 
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rate  and 
below  is 
w i t h the 


type  of  ARPANET  access,  much  of  the  protocol  described 

similar  to  the  protoeol  for  communication 

stations  and  for  eonnun icat ion  with  the  SIP  and  DP. 


1.3  Organization  of  this  Document 


In  section  2 the  content  and  format  of  the  data  beinr 
exchanged  over  the  communication  system  are  specified. 

These  data  must  be  embedded  in  nessares  that  include 
routine  and  error  control  information.  The  message  formats 
are  described  in  section  3. 

Finally  the  operating  protocols  or  rules  for  the  exchange 
of  data  and  control  nessares  are  specified  in  section  4. 

2.  Data  formats  from  the  360/44  to  the  CCP. 

The  only  data  sent  from  the  360/44  to  the  CCP  is  block  data 

for  the  VELA-3  circuit.  The  format  of  the  block  data  is  as  follows 

Field  1 : bytes  0 and  1:  Number  of  bytes  in  field  3 

Field  2:  bytes  2 and  3.’  Id  and  status  word  for  the  VELA-3 

header 

Field  3:  VELA-3  block  data  for  one  second. 

? . ' | o r a - e Forma t s 

3 . : 36 0 / 4 4 to  C C P 


The  message  format  for  the  VELA- 3 block  data  nessare 


is  as  follows: 


Field  1 : bytes  0 to  3*  Host-IMP  leader 
(see  [4]) 

bit  1 ; priority  bit  = 0 

bits  2-8;  zeros 

bits  d-10;  destination  Host  number 
bits  11-16;  destination  IMP  number 
bits  17-28;  link  number 
bits  2D- 32;  zeros 

Field  2:  byte  •* ; Eour^e  Host  id 

Field  3 • bvte  r : Mess a re  type  = 12 

Field  4:  bytes  6 and  7:  Unique  messare  id 


Field  5:  VELA-3  block  data  (see  section  2.0) 


I 
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Field  6:  2 byte  checksum  for  fields  2,3  4 and  5: 

Checksum  defined  as  a 16  bit  number  computed 
by  subtracting  the  arithmetic  sum  of  the 
values  of  the  16  bit  words  in  the  checked  fields 
from  the  number  of  16  bit  words  in  the  checked  fields 
using  two's  complement  Dinary  arithmetic. 

3.2  CCP  to  360/4*4 

The  only  messages  sent  from  the  CCF  to  the  360/44  are 
acknowledge  messages  with  the  following  format: 


Field  1: 

Field  2: 
Field  3: 
Field  4: 
Field  5: 


bytes  0 tc  3*  Host-IMP  leader: 

(same  format  as  for  VELA-3  block  data  message  in 
section  3 . • ) 

byte  4:  Source  Host  id 

byte  5:  message  type  =1 

bytes  6 and  7:  Unique  id  of  message  being  acknowledged 

bytes  8 and  9:  Checksum  on  fields  2, 3, and  4 
(computed  as  for  VELA-3  block  data  m age 
described  in  section  3*1) 


4.  Operating  Procedures 


Whenever  there  is  a new  sequence  of  block  data  to  be 
transmitted  , the  360/44  begins  the  transmission  by  sending 
the  first  VELA-3  block  data  message  to  the  CCP.  Thereafter, 
the  360/44  will  send  the  next  message  in  the  sequence  whenever 
an  acknowledge  is  received  for  the  previous  message.  If  no 
acknowledge  is  received  after  approximately  2 seconds  the 
previous  message  is  repeated. 

Whenever  the  CCP  receives  a VELA-3  block  data  message 
with  the  correct  checksum  and  a new  message  id,  the  block  length 
field  will  be  compared  with  the  available  space  for  block 
data  in  the  VELA-3  format.  If  the  block  will  fit,  the  message  is 
placed  in  a queue.  When  the  queue  length  is  less  than  4 messages, 
the  CCP  returns  an  acknowledge  message  to  the  360/44.  Thus  the 
acknowledgment  provides  flow  control. 

If  the  block  data  will  not  fit  in  the  available  space  on  the 
VELA-3  line,  the  operator  will  be  notified  and  the  message  will 
rot  be  acknowledged. 

Since  the  CCP  may  be  on  either  of  two  Host  ports,  the  360/44 
mu'jt  determine  the  correct  CCP  address.  This  may  be  done  by 
operator  input  or  the  360/44  may  send  the  first  message  of  a 
block  data  sequence  to  both  possible  CCP  addresses  and  send 
the  rest  of  the  data  to  the  address  from  which  it  receives 
an  acknowledgment. 
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SUMMARY 


Summarised  bo  low  are  the  results  of  a preliminary  analysis, 
presented  at  length  in  this  interim  report,  of  the  impact  of  the 
seismic  network  on  the  ARP A network.  During  the  course  of  this 
study,  no  insurmountable  problems  were  uncovered  which  would 
discourage  the  use  of  the  Aim  A Network  by  the  seismic  network. 

The  ARIA  Network  provides  a flexible,  reliable  data  communication 
medium  which  the  seismic  network  can  use  to  advantage  immediately, 
and  which  is  readily  capable  of  being  adapted  to  support  future 
s e i sml  c ne two:* k growl h . 

T he  i me  a c t o f t he  s e i s n i c data  o n t h e A R P A Network  will  be 
s 1 rn i f ' c a n t . P; c u g n o s t i r.a t e s 1 nd icat e t ha t w ith  the  completion 
the  seismic  network,  the  av -rage  number  of  packet s/d ay  will 
1 a i ,■  1 ■ • . ? o r. i i e q u e n 1 1 y , s ' m * g r o w th  f the  A R P A Network  will  be 
necessary  to  support  both  the  seismic  application  and  the  other 
users.  In  particular , adding  the  seismic  traffic  will  overload 
the  set  of  current  AH PA  Network  lines  in  the  region  between 
tb-iv  and  ICA,  thus  requiring  some  increase  in  the  capacity  of 


th  se  lines 

or  mod  if i cat: 

on  of  lopolog; 

struc lured , 

l h e A R P A 1 1 e*  l w 

c rk  i Pi P s at  f. 

the  t hr* ought 

u o i i •_  * c *j  *_>  o fi  i"*  y 

for  the  seism 

Puffer  space 

1 -i-  ITi  '-#1  u i.  0 > . •->  ) 

some  modifier 

w i 1 1 th e r e 1’ o r e b e n e e a e d t o a c h L e v a t h e t hr* oughput  desired. 

This  study  also  shows  that  the  delay  encountered  by  the 
or. -line  seismic  data  from  tne  station  controllers  in  the  field 
to  the  TCP  will  be  well  within  the  ten-second  requirement. 
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Summary  of  Expected  Delays 

Link  (refer  to  fit?.  1 ) 

a:  to  SPLI 

b:  SPLI-IMP 

c:  Satellite 

d+e:  ARPA  Network 

f:  IMP-CCP 

CCP  Processing 


Delay  (sec) 

1 sec 
0.14  * 

0.27-0.32  ** 

0.3-0. 5 ### 
O.71-O.85  #### 
0.1 


Total 

* Assuming  * 
delay  will 


7200-bit/sec  line.  Ar 
occur  if  a packet  must 


2.67 -3. 06  sec 

additional  0.4  second 
be  retransmitted. 


** Assuming  a reservation  protocol 
to  0.71  second  delay  w?  1 *.  occur 
retransmitted. 


. An 
if  a 


additional  0.5C 
packet  must  be 


see  ends,  and  in 


•••Marginal  lines  and  heavy  traffic  . „ 

, . y lr<11Ue  -an  cause  additional 

delays  of  the  order  of  tenths  of  , 

extremely  rare  cases  as  high  ar  5 seconds. 

****Inc ludes  d^lav  of  ^ 

, y ^^ing  for  remaining  packets  in  a 
mu  1 u.i.  — pac Ke t message. 


Summary  of  Problem  Areas 

Problems: 

Limited  amount  of  message  reassembly  buffer  space 

hho  fP/l  rnm  . . , f ■ 


(a) 

(b) 


the  CCA-TIP  and  at  SPAC . 
ingestion  of  lines  from  3DAC  to  CCA. 
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Areas  of  Concern: 

(c)  The  effect  of  the  hostile  environment  on  t VDH 
interface  error  rate  (oetween  the  SPLI  and  Satellite  IMP). 

(d)  The  ability  of  the  network  routing  algorithm  to  adapt 
quickly  enough  after  a failure  (line  or  IMP  outage) 
to  prevent  excessive  delays  from  being  encountered 

by  the  on-line  seismic  data. 

(e)  Throughout  this  report,  it  has  been  assumed  that 
satellite  communication  channels  of  the  appropriate 
bandwidth  will  exist  for  use  by  the  seismic  network. 
Obviously,  if  su°h  channels  do  not  come  into  existence, 
this  will  create  major  problem  for  the  seismic 
network. 

Summary  of  Possible  Solutions  to  Problems 

(a)  Limited  buffer  Space — This  problem  will  begin  to  be 
noticeable  at  SDAC  when  the  CCP  and  the  360/40A  are 
on  the  same  IMP  and  the  360/44  and  NORSAR  are  both 
putting  data  into  the  system,  possibly  as  early  as 
the  fall  of  1975-  It  will  become  critical  when  the 
first  SPLI  comes  on-line,  possibly  as  early  as  late 
1975  but  more  likely  in  mid-1976.  The  problem  will 
appear  at  CCA  when  non-seismic  inputs  to  the  Data- 
computer  become  significant.  We  see  three  possible 
solutions  to  this  problem: 

1.  Replace  the  affected  IMPs  by  Pluribus  IMPs.  This 
allows  additional  memory  and  processing  capability 
to  be  added  modularly  when  needed. 

2.  Install  a dedicated  IMP  for  the  SIP,  a brute-force 
but  straightforward  way  to  add  the  necessary 
additional  memory. 

3.  Add  memory  plus  the  necessary  software  changes  to 
allow  existing  IMPs  to  use  the  additional  memory. 
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Our  recommendations  are  as  follows:  For  SDAC , solution 

1.  is  the  cleanest.  Solution  3.  is  the  next  alternative, 
but  a second  IMP  must  be  provided  to  allow  the  CCP  an 
alternate  means  of  connecting  to  the  ARPA  Network.  The 
SDAC-TIP  is  not  able  to  provide  adequate  reassembly 
buffer  space.  For  CCA,  either  solution  1.  or  solution 

2.  will  suffice. 

(b)  Limited  Channel  Capacity — This  problem  will  appear 

gradually  as  the  seismic  load  increases,  probably  late 
1975  to  mid-1976  depending  on  when  the  SIP  comes  on-line. 
Possible  solutions: 

1.  Replace  affected  lines  by  230.^  Kbit/sec  lines.  ( 20%)* 

2.  Install  a direct  50  Kbit/sec  line  from  SDAC  to  CCA 
via  terrestrial  or  domestic  satellite  circuits.  ( 6 0% ) 

3.  Establish  a nearly  direct  line  by  installing  a 
Harvard-CCA  line.  ( 8 0 % ) . 

4.  Implement  bandwidth  routing**  with  no  topology 
changes.  ( 70 % on  SDAC-Belvoir  line) 

5.  Implement  bandwidth  routing  with  two  independent 
paths.  (50-6035  on  each  path) 

We  recommend  a combination  of  the  direct  line  and 
bandwidth  routing  approaches  to  provide  reliability  and 
adaptability.  For  example,  bandwidth  routing  could  be 
implemented  as  the  first  parts  of  the  seismic  network 
come  on-line  (early  1976),  with  a nearly  direct  line 
added  later  when  needed.  Finally,  as  the  full  seismic 
network  is  completed,  the  nearly  direct  line  could 
be  replaced  by  a direct  satellite  or  terrestrial  circuit. 

Figures  in  parentheses  give  percentage  of  available  data  band- 
width used  at  tightest  bottleneck.  3R0-LPE  data  is  not  included. 
Bandwidth  routing  allows  traffic  to  be  routed  simultaneously  on 
multiple  paths  to  achieve  higher  throughput  than  any  line  can 
support  singly. 
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1.  INTRODUCTION 

1 . 1 Scope  and  Purpose 

This  interim  report  contains  a preliminary  analysis  of 
the  expected  data  flow  paths  in  the  proposed  seismic  network. 

The  purpose  of  this  report  is  to  outline  potential  problem 
areas  in  the  use  of  the  ARPA  Network  to  convey  seismic  data  from 
the  field  to  a centrs.'  ized  mass  store,  and  to  suggest  possible 
ways  in  which  the  ARPA  Network  should  evolve  in  order  to  satisfy 
the  needs  of  the  seismic  application. 

1.2  Organization  of  the  Report 

This  report  is  divided  into  three  sections.  The  first, 
besides  introducing  the  body  of  the  report,  gives  a very  brief 
description  of  the  ARPA  Network  which  is  intended  to  augment 
the  reader’s  familiarity  with  that  network  and  to  provide  a 
framework  for  the  preliminary  analysis. 

In  the  second  section,  the  preliminary  analysis  of  the 
data  flow  paths  is  presented.  Section  2.1  contains  an  overview 
of  the  various  data  flow  paths.  Sections  2.2  through  2.6  describe 
the  various  parts  of  the  data  path  from  the  station  processor  to 
the  seismic  Communications  and  Control  Processor  (CCP) . Delay 
is  the  primary  concern  for  this  data  path,  since  the  data  must 
reach  the  CCP  and  be  processed  by  it  v/ithin  a time  window  of 
ten  seconds. 

Sections  2.7,  2.8,  and  2.9  deal  with  other  data  flows  for 
which  throughput  is  the  vital  parameter,  especially  in  view  of 
the  convergence  of  data  at  SDAC  (where  the  CCP  will  be  located) 
and  at  CCA  (where  the  mass  store  is  located). 
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Conclusions  and  a discussion  of  potential  problems  are 
presented  in  section  3* 

1.3  A Brief  Description  of  the  ARPA  Network 

The  ARPA  Network  is  a packet-switching  communication 
network  which  allows  dissimilar  and  geographically  separate 
Host  computers  to  communicate  reliably  and  rapidly.  The  network 
consists  of  a number  of  Interface  Message  Processors  (IMPs) 
interconnected  by  50  Kbit/sec  capacity  lines;  the  Host  computers 
are  connected  to  the  IMPs  (up  to  four  on  an  IMP).  In  addition, 
there  are  Terminal  IMPs  (TIPs)  which  allow  computer  terminals  to 
be  connected  to  the  network,  and  through  the  network  to  a Host, 
without  having  to  be  connected  directly  to  a Host  computer. 

The  IMPs  themselves  are  actually  small  mini-computers 
which  perform  the  functions  of  forming  messages  into  a succession 
of  smaller  packets,  storing  and  forwarding  the  packets  through 
the  network  to  the  destination  IMP,  retransmitting  them  as 
necessary  to  ensure  correct  receipt,  checking  the  status  of 
neighboring  lines  and  IMPs,  exchanging  routing  information  to 
find  the  most  efficient  path  through  the  network  from  source 
to  destination,  and  reassembling  the  packets  into  messages  at 
the  destination  IMP  for  transmission  to  the  destination  Host 
computer.  A basic  description  of  the  issues  of  network  design 
may  be  found  in  reference  1. 

The  ARPA  Network  has  grown  from  29  nodes  and  an  average 
of  807,164  internode  packets/day  in  Jan.  1972,  to  36  nodes  and 
1,4 55 ,325  internode  packets/day  in  Jan.  1973,  to  ^5  nodes  and 
2,965,220  internode  packets/day  in  Jan.  197^.  During  197^  the 
traffic  growth  rate  has  slowed  considerably,  until  currently 
the  average  is  between  3-8  and  ^4.0  million  packets/day;  the 
number  of  nodes  has  grown  to  55.  Figure  2 shows  the  current 
network  topology. 
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2.  PRELIMINARY  ANALYSIS  OF  DATA  FLOW  PATHS 
2.1  An  Overv i ew 

A logical  map  of  the  seismic  network  was  shown  as  figure  1. 
Seismic  data  will  be  collected  at  the  overseas  sites  by  a 
station  processor  at  each  site  (KSRS,  ILPA,  SITE  II)  and  passed 
to  a Seismic  Private  Line  Interface  (SPLI)  which  looks  like 
a modem  to  the  station  processor  and  like  a Host  computer  to  the 
ARPA  Network  (link  a in  figure  1). 

The  SPLIs  will  be  connected  to  overseas  Satellite  IMPs 
using  a Very  Distant  Host  (VDH)  interface  (see  reference  2).  The 
data  will  be  formed  into  data  messages  and  transmitted  from  an 
SPLI  to  its  IMP  (link  b).  The  IMP  will  break  the  data  messages 
into  packets  and  transmit  them  across  a satellite  channel  to  a 
receiving  Satellite  IMP  (link  c).  We  shall  assume  that  the  over- 
seas network  is  a natural  extension  of  the  continental  ARPA  Network, 
rather  than  a separate  network  connected  by  a "gateway”,  and  that 
Satellite  IMPs  will  be  installed  on  the  west  coast  and  east  coast. 
Conventional  satellite  (or  underwater)  circuits  could  also  be  used 
to  transmit  data  to  the  continental  United  States.  From  the 
receiving  Satellite  IMP  the  packets  will  be  passed  from  IMP  to 
IMP  (link  d)  through  the  continental  ARPA  Network  to  the  IMP 
recently  installed  at  3DAC  (link  e) . Assuming  the  present 
network  topol  gy,  this  amounts  to  about  9 hops  for  data  from  the 
Pacific  and  1 hop  for  data  from  the  Atlantic. 

All  the  on-line  seismic  data  will  converge  at  the  SDAC-IMP, 
which  will  have  as  one  of  its  Host  computers  the  Communications 
and  Control  Processor  (CCP)  for  the  seismic  network.  The  SDAC-IMP 
will  reassemble  the  transmitted  packets  into  data  messages  and 
pass  them  to  the  CCP  (link  f). 
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A ftor  be .! nr  processed  by  the  CCP,  the  data  will  be  output 
onto  the  VELA  link  as  well  as  formed  into  messages  and  sent  via 
4 he  AH PA  Artwork  to  the  Seismic  Input  Processor  ( SIP)  at  the 
CCA-T1 F in  ‘ambridge,  Mass.  (Again,  the  SDAC-IMP  will  break 
the  data  messages  into  packets  which  will  be  transmitted  and 
reus  semi  .led  at  the  CCA-TJP.  This  is  a path  of  about  8 hops.) 

In  addition,  data  will  be  sent  from  the  CCP  to  the  SDAC  360/^0A, 
from  the  CCP  to  SORSAR,  and  .long  period  data  w 1 1.1  be  sent  from 
the  mass  store  to  the  SDAC  360/403  for  analysis.  Periodically, 
long  period  data  recorded  on  magnetic  tape  will  be  sent  via  the 
ARIA  network  from  Albuquerque,  U.M.,  destined  for  the  SIP. 

It  is  important  to  bear  in  mind  the  delay  and  throughput 
-•nstraints  which  must  be  met  in  order  that  the  seismic  network 
bo  effective.  First,  the  delay  from  the  station  processor 
through  the  CCP  must  be  kept  below  ten  seconds.  This  maximum 
delay  was  chosen  because  it  provides  a good  compromise  between 
expected  transmission  delays  and  buffering  needed  to  average 
ut  those  delays.  In  this  way  the  network  can  be  used  in  a 


,.1-t  i; 


t r a n s m ' 
because 
...  m i o r ‘j  i i 
s v e ci  q , / 


e f 1 x ed  -d e 1 ay  ap pile  at  .ion. 

ere  Is  no  explicit  delay  requirement  for  data  being 
ted  from  the  CCP  to  the-  DIP,  but  a bound  is  implied 
of  the  finite  buffering  ability  of  the  CCP.  It  is  more 
t to  consider  throughput  for  this  data,  since  adequate 
hroughpu t implies  that  the  CCP  will  never  become 


"backed  up"  with  data  destined  for  the  SIP. 

Similarly  it  is  important  to  consider  the  required 
throughput  for  the  other  data  flow  paths  in  the  seismic  network. 

V/e  will  begin  by  examining  the  delay  constraints  along 
the  various  parts  of  the  path  from  a station  processor  through 
the  CCP,  and  then  examine  the  throughput  requirements  for  the 
data  i low  paths . 
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2.2  Station  Processor  to  SPLI  (link  a) 

The  SPLI  will  be  designed  to  look  like  a modem  from  the 
station  processor^  point  of  view.  The  rate  of  data  transfer 
will  be  real-time;  that  is,  it  will  take  one  second  to  transfer 
a second* s worth  of  seismic  data  from  the  station  processor  to 
the  SPLI. 

If  the  SPLI  is  located  at  the  station  processor  site,  the 
propagation,  or  speed-cf-light , delay  will  be  negligible.  If 
the  SPLI  is  located  some  distance  away,  the  delay  is  1 msec/186 
miles,  or  about  ',.4  msec/1000  miles. 

It  takes  one  second  for  the  station  processor  to  assemble 
a second* s worth  of  data  into  a message.  As  the  message  begins 
to  be  transmitted  to  the  SPLI,  it  is  stamped  with  the  time  of 
day.  From  the  time  of  this  stamp  through  the  processing  by  the 
CCP,  a maximum  of  ten  seconds  can  elapse.  One  second  is  used  to 
transmit  the  data  message  from  the  station  processor  to  the  SPLI 
(excluding  propagation  delays).  Therefore,  nine  seconds  remain 
to  cover  the  variable  delays  encountered  in  the  remainder  of 
this  data  flow  path. 

2.3  SPLI  - Satellite  IMP  (link  b) 

There  are  two  possible  locations  for  the  SPLI.  The  first 
is  at  the  site  of  the  station  processor.  This  location  is  pre- 
ferable from  the  point  of  view  of  reliability,  since  the  line 
traversing  the  most  hostile  environment  will  contain  error-det- 
ection and  receipt  acknowledgment  as  well  as  data.  The  second 
possible  location  for  the  SPLI  is  at  the  site  of  the  Satellite 
IMP.  In  this  case  the  data  line  will  be  traversing  the  most 
hostile  environment  and  the  data  may  be  erroneously  altered 
without  detection. 
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We  will  assume,  for  the  sake  of  argument,  that  the  SPLI 
will  be  located  at  the  station  processor  site.  The  SPLI  is 
interfaced  to  the  Satellite  IMP  using  the  Very  Distant  Host  (VDH) 
protocol.  Briefly,  this  protocol  calls  for  a Reliable  Transmission 
Package  (RTP)  for  the  data  including  "Hello”  and  "I  heard  you" 
messages  to  verify  the  integrity  of  the  communication  channel. 

The  sending  side  of  the  RTP  will  break  up  the  data  messages  into 
packets  of  1008  bits  or  less  and  transmit  them.  The  receiving 
side  of  the  RTP  will  transmit  an  acknowledgment  for  every  packet 
correctly  received.  If  an  acknowledgment  is  not  received  at  the 
sending  side  after  some  time  (called  the  retransmit  time),  the 
packet  is  retransmitted. 


Currently  this  retransmit  time  is  on  the  order  of  2R0  msec, 
but  this  may  need  to  be  adjusted.  The  tradeoff  is  this:  if 

the  retransmit  time  is  too  short,  the  sending  side  will  overburden 
the  receiving  side  by  sending  packets  more  often  than  necessary, 
thus  cutting  the  effective  bandwidth  of  the  SPLI-Satellite  IMP 
link.  If  the  retransmit  time  is  too  long,  inordinate  delays 
for  lost  or  altered  packets  will  be  introduced  which  will 
increase  the  effective  delay. 

A good  compromise  is  to  set  the  retransmit  time  equal 
to  the  maximum  expected  round-trip  delay  time  (the  time  from 
packet  transmission  to  receipt  of  acknowledgment).  This  can  be 
calculated  as  follows.  First  calculate  the  propagation  delay 
L based  on  the  distance  Detween  the  SPLI  and  the  Satellite  IMP. 

Then  calculate  the  one-way  transmission  delay  T for  a full 
packet  by  dividing  the  packet  length  by  channel  capacity.  It 
will  take  L+T  seconds  for  the  packet  to  reach  the  receiving  side. 
Acknowledgments  are  "piggybacked"  on  return  packets  (when  possible). 
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If  there  is  one  packet  in  the  output  queue  ahead  of  the  packet 
on  which  the  acknowledgment  will  ride,  it  will  take  T seconds 
to  output  the  first  packet,  T seconds  to  output  the  second,  and 
L seconds  before  the  second  packet  (and  the  acknowledgment ) 
arrives  at  the  sending  side.  Thus  the  maximum  expected  round-trip 
delay  is  2L  plus  3T.  Table  2.1  shews  this  maximum  delay  value  for 
various  channel  capacities. 


TABLE  2.1  186  miles 

(times  in  milliseconds) 


L 

T 

2L  plu 

2400 

1 

417 

1253 

4800 

1 

208 

626 

7200 

1 

139 

419 

9600 

1 

-=r 

o 

rH 

314 

50,000 

1 

20 

62 

The  additional  increase  in  delay  for  distances  up  to  1000 
miles  is  less  than  10  msec. 


The  round  trip  delay  will,  in  general,  be  less  than  this 
computed  maximum  since  the  output  queue  may  be  empty  and  the 
acknowledgment  may  be  returned  on  its  own  short  packet  instead 
of  piggybacked  on  a long  one. 


In  order  to  keep  throughput  high,  the  VDH  protocol  allows 
two  packets  to  be  "in  flight",  but  the  sending  side  must  receive 
an  acknowledgment  for  *-he  first  packet  before  the  third  packet 
can  be  sent.  However,  it  should  be  noted  that  it  is  relatively 
simple  to  alter  the  VDH  protocol  to  allow  four  packets  in  flight, 
if  that  is  necessary  for  higher  throughput. 

It  is  also  important  to  consider  the  "catch  up"  capability 
of  the  VDH  link.  Since  this  link  is  over  a hostile  environment 
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For  KSHS  and  Site  TT  t-ho  j-*. 

including  overhead  c rate  ^ 5066  blts/sec 

g overhead.  Consequently,  a '.">00  bits/sec  nne  is 

not  a <a equate  for  these  sites  -r  n ■ ^ 1 

50  Kbit/sec  line  is  used,  the  tine  r ’ 17  ' % bltS/SeC’  or 
in  Table  2.2.  * ^ 10  catch  UP  is  given 


TABLE  2.2 


Catch-up  Times 


l^ata^frame  (5066  bits_) 
7200  2.37^  sec 

9600  1.117  sec 

50,000  0.113  sec 


8.  data  frames 
18.992  sec 
8*939  sec 
0*902  sec 


r or  ILPA,  the  data  rate  1 q I'j/io 

using  a 2400  or  4800  bit<*/„,-„  14  A SPLI 

' *■ ' iine  are  shewn  in  Table  2. 3. 


TABLE  7 _j_ 


Catch-up  Rates  for  ILPA 


l_data  frame  (13^2  bits_) 
bits/sec  2i)00  1.268  sec 

^00  0.388  sec 


B data  frames 
10.147  sec 
3.105 
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Obviously,  the  higher  the  channel  capacity,  the  faster 
the  catch-up  rate.  However,  high  channel  capacity  is  expensive 
or  perhaps  not  available,  and  at  seine  point  (between  18  Kbit/sec 
and  3?  Kb  it/sec)  the  satellite  link  or  the  ARP A Network  itself 
will  become  the  tightest  bottleneck. 

Perhaps  another  important  measure  to  keep  in  mind  is  the 
amount  of  time  needed  to  catch  up  after  a delay  introduced  by 
a lost  or  altered  packet.  If  we  take  the  maximum  round-trip 
delay  (Table  2.1)  as  the  retransmit  time,  and  use  the  retransmit 
time  as  the  estimate  of  the  delay  introduced  by  a lost  or  altered 
packet  (generally  the  delay  will  be  less,  since  the  VPH  protocol 
allows  two  packets  in  flight),  then  the  required  catch-up  time 
is  given  for  YJ 
Table  2.5. 

TABLE  2.  <4  Cate 


bits/ sec 


. and  SITE  II 

in  Table  2.4  and  for 

ILPA  in 

up  times  to 

offset  delay  due  to  a 

lost  packet 

KSRS  & Site 

II  (5066  bits/seo ) 

Maximum  tolerable 
ave.  error  rate 

7200 

0.995  sec 

17% 

9600 

0.357  sec 

36% 

50,000 

0.0075  sec 

96% 

up  times  to 

offset  delay  due  to  a 

lost  packet 

ILPA  (1342 

bits/sec  ) 

Maximum  tolerable 
ave.  error  rate 

bits/sec 


2400 

4800 


1.585  sec 
0.243  sec 


33$ 

16% 
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These  times  are  directly  related  to  t’  e average  error 
rates  which  the  VDH  link  can  sustain  without  getting  behind, 
also  shown  in  Tables  2.*J  and  2.5*  For  example,  the  first  entry 
in  Table  2.';  indicates  that  it  would  take  roughly  a second  to 
catch  up  after  losing  one  packet  (on  a 7200  bits/sec  line  with 
a 5066  bits/sec  data  rate).  So  this  line  could  sustain  an 
average  error  rate  of  about  one  bad  packet  in  six,  or  1755. 

Again,  the  higher  the  channel  capacity,  the  higher  the  average 
error  rate  the  channel  will  be  capable  of  sustaining  while 
maintaining  the  necessary  5066  bits/sec  throughput  rate.  Keep 
in  min'  -at  this  is  an  average  error  rate.  It  is  certainly 
possibl  to  overflow  the  SPLI’s  buffering  capacity  if  a number 
of  packets  in  succession  are  lost  and  must  be  retransmitted. 

In  the  event  '"hat  channels  with  a high  capacity  are 
difficult  or  impossible  to  acquire,  it  should  be  possible  to 
use  lower  capacity  lines  in  parallel.  Since  an  IMP  has  provision 
for  up  to  four  Posts,  lines  from  the  JPLI  running  in  parallel 
could  be  attached  to  different  Host  ports  at  the  IMP. 

It  would  be  reassuring  perhaps  to  simulate  this  link 
with  an  " error-prone"  line  to  estimate  error  rates  and  the 
effect  that  altering  the  retransmit  time  in  the  VDH  protocol 
may  play  at  various  error  rates.  On  the  other  nand , it  may 
be  difficult  to  accurately  simulate  the  actual  conditions  which 
will  be  encountered  in  the  field  and  get  meaningful  results. 
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2.4  Sa tel  1 i te  hop  (link  c ) 

Various  methods  have  been  proposed  for  allowing  packet- 
switching  communications  over  satellite  channels.  Reference 
3 describes  the  Slot4rd  ALOHA  protocol  (among  others),  which 
is  well  suited  for  b...  ty,  interactive  communication.  It  is  not 
very  well  suited  to  high-throughput  continuous  data  transfers 
because  the  maximum  effective  bandwidth  is  only  36%  of  the  circuit 
bandwidth. 

For  the  seismic  network,  one  would  obviously  want  to  use 
the  circuit  bandwidth  more  efficiently,  and  so  some  reservation  pro- 
tocol should  be  implemented.  A reservation  protocol  would  avoid  the 
problem  of  packets  from  different  sources  ,fcolliding,,  at  the 
satellite  and  having  *-o  be  retransmitted,  since  time  slots  would 
be  reserved  in  advance  for  the  seismic  data  packets.  Reference 
3 also  describes  such  protocols. 

Let  us  assume  that  14.  t Kbits/sec  is  reserved  for  the  on- 
line seismic  data  ('^200  bits/sec  each  for  KSHE  and  SITE  II 
for  example)  out  of  a 50  Kb^t/sec  satellite  circuit.  Then  the 
expected  delay  is  20  msec  for  transmission  plus  250  msec  for 
propagation.  Additional  delays  v f as  much  as  100  msec  may  be 
incurred  by  some  packets  while  waiting  for  r reserved  slot. 

The  transmission  time  will  increase  for  slower  circuits 
up  to  a maximum  of  70  msec  for  a 14.4  Kbit/sec  channel.  (Cir- 
cuitry with  channel  capacities  below  14.4  Kbits/sec  would 
not  provide  adequate  bandwidth. ) So  we  may  expect  delays  of 
270  to  320  msec  (depending  cn  channel  capacity)  for  the 
satellite  hop  using  a reservation  protocol. 

If  a retrans  ssion  is  necessary,  this  would  add  a delay 
of  560  to  710  msec  using  the  2L+3T  formula. 
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It  is  possible  to  use  conventional  IMPs  and  communication 
circuits  (which  happen  to  use  satellite  circuits  or  underwater 
cable  circuits)  instead  of  Satellite  IMPs  and  a reservation  pro- 
tocol. This  is  done  now  to  allow  NORSAR,  London,  and  Hawaii  to 
connect  to  the  ARPA  Network.  These  existing  satellite  links  have 
too  low  a throughput  rate  (insufficient  for  the  proposed  seismic 
data  flow)  because  of  circuit  limitations  for  the  Atlantic  hop  and 
because  of  buffering  limitations  for  the  Pacific  hop. 

If  conventional  leased  satellite  circuit'-  are  used,  ade- 
quate bandwidth  must  be  provided  for  the  proposed  data  rates  plus 
additional  bandwidth  to  allow  ’’catching  up”.  This  would  mean 
leasing  circuits  of  at  least  7200  bits/s'-  h for  KSRS  and 

SITE  II,  4800  bits/sec  for  NORSAR,  and  24b  s/sec  for  ILPA. 

The  expected  delay  for  a satellite  hop  configured  in  this  way 
would  be  about  250  msec  due  to  propagation,  and  about  140-420 
msec  due  to  transmission  (depending  on  channel  capacity),  for 
a total  delay  of  around  400-700  msec.  Retransmissions  would 
introduce  delays  of  t he  order  of  1-2  seconds. 

2.5  The  Continental  ARPA  Network  (links  d and  e) 

The  ARPA  Network  in  the  continental  United  States  is 
the  strongest  link  in  the  path  from  the  3PLI  to  the  CCP. 

A variety  of  delay  and  throughput  statistics  reports  exist  for 
the  network  which  indicate  that  delay  will  be  no  problem, 
except  in  extraordinary  circumstances. 

Theoretical!^ > the  minimum  round  trip  delay  for  a coast- 
to-coast  path  of  10  hops  is  about  400  msec  for  a 5-packet  data 
message,  with  the  one-way  transmit  time  for  the  message  accounting 
for  about  325  msec.  Data  from  the  Network  Measurement  Center 
(reference  4)  indicates  that  the  average  round  trip  delay  times 
for  a coast-to-coast  path  are  about  150  msec.  (This  shorter  time 
is  due  to  using  shorter  messages,  one  or  two  packets  long.) 
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Another  interesting,  and  relevant,  measurement  (reference  5) 
was  made  cn  messages  sent  from  Norway  to  Hawaii  using  the  ARP A 
Network.  This  included  two  satellite  hops  as  well  as  the  coast- 
to-coast  hop.  Short  (one  packet)  messages  had  an  average  round 
trip  delay  of  1.62  seconds,  and  long  (eight  packet)  messages  had 
an  average  round  trip  delay  of  *1.76  seconds. 

Longer  delays  can  be  introduced  by  heavy  traffic,  marginal 
lines,  or  equipment  outages.  In  the  case  of  heavy  traffic, 
additional  delay  will  be  caused  by  a packet  having  to  wit  in  the 
output  queue  of  each  IMP  before  being  transmitted  to  th i next  IMP. 
Each  IMP  can  have  up  to  eight  packets  in  its  output  queue,  and  it 
takes  about  20  msec  to  transmit  each  packet  in  the  queue.  In  the 
nine  hops  from  the  west  coast  Satellite  IMP  to  the  SBAC-IMP, 
this  would  add  at  most  ( 7 x 9 x 20  = ) 1.26  seconds  of  delay. 
However,  if  all  of  the  IMF’s  output  buffers  were  constantly  full, 
this  may  imply  a throughput  bottleneck.  So  in  the  case  of  heavy 
traffic,  throughput  is  the  mere  critical  variable. 

Throughput  summaries  are  compiled  monthly  for  the  ARPA 
Network.  Recent  summaries  (reference  6)  indicate  that  the  most 
heavily  traveled  link  which  the  seismic  network  would  use  has  an 

average  traffic  density  of  11%  of  the  usable  data  channel 

* 

capacity.  A rule  of  thumb  for  estimating  the  peak  traffic 
density  is  that  it  is  between  three  and  four  times  the  average 
traffic  density.  (This  rule  comes  from  observation  of  daily 
and  hourly  throughput  summaries.  A plausibility  argument  can 
be  made  by  averaging  over  a hour  work  week  rather  than 


'* u 1 1 1 6 6 h o u r v; e ek  . ) T3 


at  peak  times  the  usual  traffic 


will  use  up  to  of  the  usable  capacity. 


Of  course,  this  IT  gore 
b e c o me s on e ratio n a 1 


may  grow  before  the  seismic  network 
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Data  from  KSRS  and  Site  II  will  be  using  this  link  on  the 
coast-to-coast  hop,  and  will  need  about  25%  of  the  usable  capacity. 
This  leaves  about  30^  (at  peak  times)  for  other  traffic,  or  for 
growth  of  existing  traffic. 

Delays  may  also  be  caused  by  marginal  lines,  leading  to 
altered  or  lost  packets.  Between  IMPs,  the  retransmit  time  is 
200  msec.  A sending  IMP  will  retransmit  a packet  every  200 
msec  until  it  receives  an  acknowledgement  from  the  receiving 
IMP.  The  average  error  rate  between  IMPs  is  about  one  bad 
packet  in  10  , so  rarely  will  any  appreciable  delay  result  from 
IMP-to-IMP  retransmissions.  (Even  if  every  line  in  the  path  from 
Ames  to  3D AC  were  marginal  so  that  each  packet  had  to  be  trans- 
mitted three  times  before  it  was  received  correctly,  the  resulting 
additional  delay  would  only  be  3.6  seconds.) 

Equipment  outages  (lines  or  IMPs)  pose  the  most  interesting 
delay  problems.  If  a certain  path  is  no  longer  working  (because 
a line  is  declared  dead  or  an  IMP  has  crashed),  then  the  routing 
algorithm  must  reroute  the  packets  around  the  dead  path.  Order 
of  magnitude  estimates  indicate  that  the  routing  algorithm  may 
take  from  1-10  seconds  before  settling  down  to  a new  equilibrium. 
Therefore  it  is  possible  that  an  equipment  failure  may,  without 
causing  the  failure  of  the  network,  cause  delays  of  the  order  of 
10  seconds  for  a few  packets. 

Again,  it  would  be  reassuring  to  make  appropriate  delay 
measurements  on  the  ARPA  Network  while  selectively  disabling 
an  IMP  or  a line.  However,  this  may  not  be  possible  to  do 
because  of  the  interference  it  would  cause  with  other  users. 

In  the  absence  of  these  measurements,  the  following  comments 
about  the  reliability  of  the  ARPA  Network  are  reassuring. 
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Recent  statistics  (reference  6)  indicate  that  the  average 
IMP  outage  is  around  1%  (one-third  of  that  for  preventive 
maintenance,  retrofitting,  and  other  scheduled  downs).  The 
statistics  for  the  month  of  August  * 7*]  reveal  that  the  mean 
time  between  failures  ( MTBK ) for  a particular  line  is  A77.5 
hours,  or  about  20  days.  The  MTBK  for  an  IMP  is  3 hours. 

(If  only  hardware/software  failures  are  included,  and  not 
scheduled  down  time,  the  MTBK  is  473  hours.) 


If  we  examine  an  ARPA  Network  path  with  10  IMPS  and  9 
lines,  and  consider  the  failures  between  the  lines  and  IMPs 
to  be  independent,  the  MTBK  for  the  path  is  16. 7 heirs  (25.0 
hours  if  only  the  hardware/sof tware  failures  are  included  for 


IMPs).  However,  this  does  not  necessarily  mean  that  data  wi]l 
be  lost  or  delayed  beyond  ten  seconds  whenever  a line  or  an 
IMP  tails.  Depending  on  circumstances,  the  routing  algorithm 
ill  usually  be  able  to  re-route  data  packets  around  the  problem 
ind  to  the  destination  within  the  ten-second  window. 
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2.G  SDAC-IMP  to  CCP  (link  f) 

The  Communications  and  Control  Processor  (CCP)  will  act 
as  a network  control  center  for  the  seismic  network.  It  will 
a Hos  u on  the  oDAC— IMP,  with  the  possibility  of  being  a 
Hos u on  the  oDAC— TIP  (should  the  IMP  fail).  Since  all  the 
seismic  data  is  destined  for  the  CCP,  the  SDAC-IMP  must  receive 
all  incoming  data  packets,  reassemble  them  into  messages,  and 
transmit  them  to  the  CCP. 

Alter  the  first  packet  of  a message  has  arrived,  the 
SDaC-iMP  must  wait  for  the  remaining  packets  to  arrive  in  order 
to  reassemble  the  message.  This  delay  will  be  about  0. 56-0. 7 seconds 
for  the  Pacific  sites,  and  somewhat  less  for  ILIA  and  NQR3AR. 

iu  nas  been  estimate* a that  tno  amount  of  data  being  received 
by  the  e or  over  tno  network  will  bo  about  lb  Kbits/sec.  Thus, 
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it  would  take  at  most  150  msec  to  transmit  the  reassembled 
messages  from  the  SDAC-IMP  to  the  CCP,  assuming  a Host-IMP 
interface  capacity  of  at  least  100  Kbits/sec.  In  addition,  the 
CCP  will  output  about  45  Kbits/sec  which  must  pass  through  the 
SDAC-IMP.  About:  22  Kbits/sec  will  be  destined  for  the  360/40A, 
about  21  Kbits/sec  will  be  destined  for  the  Seismic  Input  Pro- 
cessor (SIP),  and  about  2.4  Kbits/sec  will  be  destined  for 
N OHS AH. 

It  may  be  desirable  to  have  the  CCP  and  the  360/40A 
as  Hosts  on  the  same  IMP.  Then  the  22  Kbits/sec  data  from  the 
CCP  to  the  360/40A  would  not  traverse  any  ARPA  Network  lines 
and  would  not  add  to  the  throughput  burden  of  those  lines. 
Alternatively,  if  the  CCP  is  a Host  on  the  SDAC-IMP  and  the 
360/4GA  is  a Host  on  the  SDAC-TIP,  then  approximately  25-30 
Khlts/sec  of  data  will  be  on  the  link  from  the  SDAC-IMP  to  the 
SDAC-TIP.  Obviously,  in  this  case  it  is  advisable  to  use  a high 
capacity  modem  by-pass  for  that  link. 

The  final  step  in  this  path  where  delay  is  the  primary 
concern  is  processing  by  the  CCP  and  outputting  data  on  the 
VELA  link.  The  processing  time  should  consume  at  most  100 
msec,  and  so  does  not  add  significantly  to  the  delay. 

2.7  CCP-SIP  (links  f,e,i,  and  j) 

After  the  CCP  has  received  the  seismic  data  (within  the 
ten-second  delay  window),  the  data  is  reformatted  and  transmitted 
to  the  Seismic  Input  Processor  (SIP)  at  CCA.  The  expected 
data  rate  from  the  CCP  to  the  3IP  is  about  21  Kbits/sec,  and 
the  path  through  the  ARPA  Network  is  eight  hops  long.  (Actually, 
at  present  there  are  three  possible  eight-hop  paths  with  some 
linos  in  common. ) 
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The  21  Kbits/sec  data  rate  is  about  55$  of  the  available 
data  bandwidth.  Currently  the  average  traffic  on  the  paths 
between  SDAC  and  CCA  is  about  8$  with  estimated  peaks  of  about 
30%.  Therefore,  there  is  barely  enough  bandwidth  available 
for  the  transmission  of  this  seismic  data,  and  there  is  very 
little  room  for  growth  or  transmission  of  other  seismic  data 
during  prime  usage  hours. 

In  addition,  there  are  f.ome  characteristics  of  the  CCA-TIP 
which  will  have  to  be  altered  in  order  to  fully  utilize  the 
available  bandwidth.  First,  since  the  CCA-TIP  is  a Terminal 
IMP,  its  processor  must  spend  time  servicing  the  user  terminals. 
Preliminary  experiments  indicate  that  this  will  not  hinder  the 
throughput  of  the  seismic  data.  Sufficient  processor  bandwidth 
is  present  for  doing  both  tasks  adequately. 

Second,  one  of  the  Hosts  (the  Lincoln  Laboratory 
Cambridge  Field  Station  PDP-11)  is  connected  to  the  CCA-TIP 
via  the  VDH  protocol.  This  protocol  "borrows"  buffer  space 
from  the  IMP  program  which  the  IMP  program  could  use  for 
reassembling  the  packets  into  messages.  If  buffer  space  is 
not  reserved  for  reassembly  at  the  destination  IMP,  the  source 
IMP  will  not  transmit  the  message.  Consequently,  if  the  VDH 
protocol  "borrows"  too  many  buffers,  the  throughput  rate  will 
suffer. 

Preliminary  analysis  indicates  that  removal  of  the  VDH 
interface  would  provide  enough  buffer  space  for  the  seismic  network 
alone.  However,  as  the  CCA  Datacomputer  is  used  more  and  more  for 
file  storage  and  retrieval  by  others,  a shortage  of  message  re- 
assembly buffers  will  eventually  develop  even  with  the  removal  of 
the  VDH. 

Currently,  throughput  experiments  are  being  planned  to 
determine  to  what  extent  any  throughput  limitations  are  line 
dependent,  buffer  dependent,  VDH  dependent,  or  processor  dependent. 
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2.8  SRO  and  LPE  Data  (links  k,i,  and  jj 

The  Seismic  Research  Observatories  (SRGs)  and  Long 
Period  Experiment  (LPE)  sensors  will  have  their  data  recorded 
on  magnetic  tape.  It  is  estimated  that  daLa  Prom  all  the  SROs 
and  LPEs  will  amount  to  about  1600  bits/sec.  Every  two  weeks, 
the  recorded  data  (about  l.q  x IQ9  bits)  is  sent  to  the 
Albuquerque  Seismoiogical  Center  for  examination.  Then  the 
data  is  to  be  sent  to  the  m&ss  store  via  the  ARPA  Network. 

i 

Obviously,  such  a tremendous  amount  of  data  cannot  be 
dumped  onto  the  present  network  without  causing  network  congestion. 
For  example,  the  lines  from  Albuquerque  to  the  east  coast  are  the 
most  neavily  utilised  in  the  Network,  and  the  on-line  seismic 
data  from  the  Pacific  sites  will  use  these  lines  as  well. 

Dumping  would  saturate  these  lines  causing  "back-ups11  and  long 
delays  for  the  on-line  seismic  data.  In  this  case  the  network 
would  oe  forced  to  "meter”  the  incoming  data  at  a non-detrimental 
rate,  or  "grow”  (by  installing  higher  capacity  lines)  to  absorb  it. 

A simple  way  to  avoid  this  problem  Is  to  transmit  the 
SRQ-LPE  data  at  low  rates  over  an  extended  period  of  time.  For 
example,  if  the  data  transfer  is  spread  out  over  two  weeks  and 
is  done  only  at  night  (to  avoid  competition  with  normal  network 
traific;,  the  bandwidth  needed  would  be  around  3200  bits/sec. 

Along  this  seme  line,  it  might  be  prudent  to  consider  the 
use  of  other  means  of  transmitting  the  SRO- LPE  data  to  the  mass 
store  (e.g.  mailing  the  tapes  to  CCA). 
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2.9  Long  Period  Data  Examination 

The  long  period  data  from  all  sites  (ILPA,  ALPA,  KSRS, 

Site  IT,  MORSAR,  LASA , SROs,  and  LPKs)  stored  at  CCA  will  be 
examined  by  seismic  analysts  at  SDAC . Thus  a user  on  the  SDAC 
360/40B  will  be  retrieving  files  through  the  SIP  at  various 
times  during  the  working  day. 

The  long  period  data  is  accumulated  at  the  rate  of  about 
5 Kbits/sec  or  about  4.3  x 10**  bics/day.  If  the  analyst  at  SDAC 
wishes  to  see  50$  of  this  data  during  an  8-hour  work  day,  that 
amounts  to  an  average  throughput  of  7-5  Kbits 'sec  during  the  day, 
with  peaks  much  higher.  This  represents  a significant  through- 
put demand  (about  a 20$  average  demand)  on  the  ARPA  Network. 

In  addition,  the  retrieval  and  examination  of  short-period  SRO 
data  could  add  another  1 Kbit/sec  to  this  data  flow.  Fortunately, 
since  full  duplex  lines  a.-e  used,  this  demand  will  not  interfere 
with  traffic  traveling  in  the  other  direction  (from  SDAC  to  the 
SIP).  However,  it  will  add  to  the  competition  for  buffer  space 
at  SDAC. 

For  oxamf  -e , at  the  CCA-TIP  we  will  have  21  Kbits/sec 
coming  from  the  CCP,  in  addition  to  the  SRO  and  L.PK  data,  and 
an  average  of  7*5  Kbits/see  going  to  the  360/40:3  at  SDAC.  In 
addition  the  TIP  must  support  the  usual  ARPA  Network  traffic 
(average  about  2.4  Kbits/sec  with  peaks  estimated  at  9*6 
Kbits/sec)  plus  any  demands  for  data  from  the  CCA  Dataeomputer 
by  other  users.  At  SDAC,  about  15  Kbits/sec  is  coming  into  the 
CCP  and  about  45  Kbits/sec  is  going  out,  21  Kbits/sec  destined 
for  the  SIP,  22  Kbits/sec  destined  for  the  360/40A  and  2.4 
Kbits/sec  for  NQRSAR . The  SDAC  360/40B  will  receive  an  average  7.5 
Kbitr/sec  (with  higher  peaks).  With  such  throughput,  the  demands 
on  buffer  space  at  CCA  and  SDAC  are  severe. 
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3.  CONCLUSIONS  AND  DISCUSSIONS  OF  PROBLEMS 

The  preliminary  study  reported  on  here  considered  the 
effect  on  the  ARPA  Network  of  the  proposed  volume  of  seismic 
data  to  he  carried  by  the  network.  The  study  consisted  of 
examining  the  proposed  seismic  data  flow,  theoretical  delay 
and  throughput  results,  as  well  as  available  delay  and  through- 
put measurements. 

The  study  Indicates  that  seismic  data  from  the  field 
stations  will  be  able  tr  reach  the  CCP  within  the  allotted 
ten-second  interval. 

There  are  two  serious  expected  problems  which  will  affect 
the  network’s  throughput  capability  for  seismic  data.  (See 
reference  7 for  a discussion  of  network  throughput.)  The  problems 
arise  from  a limited  amount  of  buffer  space  for  message  reassembly 
in  the  destination  IMPs  and  the  channel  capacity  of  certain  lines 
which  the  seismic  data  is  expected  to  employ. 

In  the  day-to-day  use  of  the  network,  these  problems 
are  not  encountered  since  traffic  .is  more  distributed  and  ’’bursty". 
In  contrast,  the  seismic  data  will  be  a continuous  stream  of 
large  volume,  and  more  importantly,  it  will  be  converging  at  the 
CCP  and  the  mass  store. 

Specifically,  the  present  CCA-TIP  will  not  be  able  to 
handle  the  expected  amount  of  se ' *mic  data  being  sent  to  the  mass 
store  because  of  insufficient  messages  reassembly  buffer  space 
for  the  volume  of  seismic  data  converging  at  CCA.  In  addition, 
a Very  Distant  Host  (7DH ) interface  used  by  one  of  the  CCA-TIP’s 
Hosts  contributes  to  the  oroblera,  it  would  be  sensible  to  move 

i 

the  YDH  interface  to  a different  IMP  (or  have  another  IMP  support 
the  mass  store).  Throughput  experiments  are  being  planned  to 
more  precisely  determine  what  measures  will  be  sufficient  to 
alleviate  this  deficiency. 
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In  addition,  a deficiency  of  buffer  space  will  also  exist 
at  the  SDAC-IMP.  This  is  due  to  the  amount  of  data  arriving  at 
the  CCF’  from  several  sources  with  round-trip  delays  of  several 
seconds.  Before  a data  message  is  sent,  reassembly  buffers  are 
reserved  for  it.  If  the  time  to  complete  transmission  of  the 
message  is  long  (2-3  seconds),  no  other  messages  can  use  these 
reserved  reassembly  buffers  during  that  time.  With  several 
sources  transmitting  simultaneously  to  the  CCP,  it  is  easy  to 
exhaust  the  buffering  capability  of  the  SDAC-IMP. 

In  view  of  the  expected  seismic  data  flows  and  current 
network  usage,  certain  network  lines  presently  do  not  have 
adequate  bandwidth  available  for  carrying  the  seismic  data  as 
well  as  o^her  traffic.  These  are  the  lines  in  the  northeast 
corridor  from  S3 AC  to  CCA. 

Basically,  the  problems  encountered  are  a scarcity  of 
certain  network  resources  (buffer  space  and  channel  capacity), 
thus,  the  possible  remedies  are  acquisition  of  more  of  the 
scarce  resource,  or  rationing  of  its  use. 

Throughput  experiments  are  being  designed  tc  determine  to 

what  extent  bottlenecks  are  due  to  buffer  scarcity  of  lack  of 

channel  capacity.  Also,  an  experiment  is  being  planned  to  ob-- 

serve  the  time  variation  of  the  available  bandwidth  on  the 

network.  This  variation  in  throughput  capability  could  prohibit 
successful  transmission  of  seismic  data  even  though  there  is 
adequate  average  throughput. 
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3.1  Message  Reassembly  Buffer  Space 


One  way  of  providing  more  reassembly  buffer  space  would 
be  to  replace  the  affected  IMP  (or  IMI  s ) by  a high-speed 
modular  (Fluribus)  IMF  (reference  8).  In  this  way,  additional 
memory,  I/O,  or  processinp  capability  could  be  added  easily 
and  only  if  needed,  and  taken  away  to  be  used  elsewhere  if  not 
needed.  This  degree  of  flexibility  may  be  desirable  in  view  of 
the  evolutionary  character  of  the  ARP A Network. 

Along  this  same  line,  installing  a separate  (dedicated) 
IMP  at  CCA  would  alleviate  the  buffer  space  problem  there.  This 
is  a brute- force  but  straightforward  way  to  add  the  necessary 
memory . 

Adding  more  rn  : . / to  affected  IMPs  is  also  a solution, 
but  it  would  entail  extensive  software  modification  to  make  use 
of  the  additional  memory. 

Of  course,  iiost-IMP  interfaces  should  have  as  high  a 
bandwidth  as  is  practical  to  facilitate  rapid  emptying  of 
buffers . 


Specifically,  at  the  CCA-TIP,  removal  of  the  VDK  interface 
is  an  adequate  short-term  solution.  This  solution  would  suffice 
until  such  time  as  usage  of  the  CCA  Datacomputer  begins  to  put 
significant  demands  for  reassembly  buffer  space  on  the  CCA-TIP. 
Currently,  we  have  no  estimate  of  projected  Datacomputer  usage 
by  those  outside  the  seismic  community.  After  such  tine,  a 
Pluribus  IMP  or  a dedicated  IMP  (with  the  SIP  as  its  only  Host) 
would  provide  adequate  buffer  capacity. 

At  SDAC,  the  problem  is  more  severe,  since  a dedicated 
IMP  (with  the  CCP  as  Its  only  Host)  -would  not  provide  enough 
reassembly  buffers  when  the  entire  seismic  network  is  on-line. 
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Here  the  cleanest  solution  is  the  Pluribus  IMP.  The  alternative 
is  to  add  more  memory  to  the  SDAC-IMP  and  make  the  necessary 
modifications  to  the  IMP  software  to  allow  the  additional  memory 
to  be  used. 

It  should  be  pointed  out  that  the  CCP  must  have  the  ability 
to  be  connected  to  the  network  in  at  least  two  ways,  so  that  the 
CCP  can  remain  on-line  when  the  SDAC-IMP  is  off-line.  The  SDAC- 
TIF,  which  was  to  provide  the  second  connection,  will  not  have 
adequate  buffering  capability  in  its  present  form. 


IMPs  and  TIPs  can  each  support  a maximum  of  32K  words 
of  memory.  Currently,  each  IMP  has  at  most  3 6 K , the  SDAC-TIP 
has  2 8 K and  the  CCA-TIP  has  28K.  However,  it  is  expected  that 
TIPs  will  need  the  last  AK  of  memory  for  terminal-handling  at 
some  future  time.  This  will  preclude  the  possible  use  of  this 
tK  of  memory  for  reassembly  buffers  in  TIPs.  Consequently, 
while  it  is  possible  tc  add  memory  for  reassembly  buffers  to 
the  SDAC-IMP , it  is  not  possible  to  use  additional  memory 
on  the  SDAC-TIP. 


The  impli cation  of  this  conclusion  is  far-reaching.  The 
CCP  will  net  be  able  to  be  a Host  on  the  SDAC-TIP  when  the  full 
seismic  network  is  in  operation . A second  IMP  with  the  memory 
and  software  modifications  recommended  for  the  SDAC-IMP  would  be 
needed  tc  provide  the  CCP  with  another  means  of  access  to  the 
APPA  Network.  (Equivalently,  the  terminal -hand ling  capability 
of  the  SDAC-TIP  could  be  moved  tc  some  other  node.  This  would 
make  the  SDAC-TIP  into  an  IMP). 


The  problem  at  SL  AC  will  not  manifest  itself  until  an 
overseas  site  (other  than  MOPS AH)  begins  transmitting  seismic  data 
to  the  CCP.  Therefore , a solution  does  not  have  to  be  implemented 
when  the  CCP  comes  on-line,  but  one  w I 1 1 have  tc  be  implemented  as 
overseas  sites  come  on-line. 


1 


Report  No.  2995 


Bolt  Beranek  and  Newman  1 !ic  . 


3.2  Channel  Capacity 

Obviously,  upgrading  the  affected  lines  from  50  Kbits/sec 
to  230.4  Kbits/sec  would  solve  the  channel  capacity  problem. 

We  believe  that  such  a drastic  solution  is  not  warranted  at 
this  time,  and  therefore  vre  suggest  two  other  approaches. 

One  approach  is  to  connect  a 50  Kbit/sec  line  directly 
from  SDAC  to  CCA  to  bypass  the  northeast  corridor  traffic. 

This  could  be  done  by  conventional  terrestrial  circuits  or  by 
a domestic  satellite  circuit  and  would  provide  the  additional 
bandwidth  necessary  to  accommodate  the  CCP-SIP  data  flow. 

(The  CCP-SIP  data  would  use  about  60%  of  the  available  data 
bandwidth  of  this  line.)  One  possible  drawback  is  that  a 
failure  of  this  new  circuit  at  an  inopportune  time  (such  as 
during  a day  with  heavy  network  traffic)  would  force  the  seismic 
data  onto  other  lines  which  then  would  become  nearly  overloaded 
(roughly  92#  of  the  available  data  bandwidth  would  be  used). 

A nearly  direct  path  (5  hops)  could  be  established  by 
installing  a line  from  Harvard  to  CCA  (a  distance  of  a few 
miles).  This  is  less  expensive  than  a direct  line,  and  would 
serve  to  improve  throughput  by  reducing  the  round-trip  delay 
(fewer  hops)  and  by  bypassing  the  busy  BBN  nodes.  The  heaviest 
traffic  would  be  between  SDAC  and  Harvard,  and  would  be  about 
80$  of  the  available  data  bandwidth.  However,  this  would 
allow  little  expansion  of  either  seismic  or  non-seismic  traffic 
along  this  route. 

The  second  approach  places  more  emphasis  on  software 
changes.  Since  there  are  two  paths  between  SDAC  and  CCA  (with 
only  the  SDAC-Belvoir  line  in  common)  the  IMP  routing  algorithm 
could  be  altered  to  allow  the  CCP-SIP  data  to  be  split  between 
the  two  paths.  At  peak  times,  each  path  would  be  loaded  to  about 
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10%  of  its  data  capacity  . Two  completely  independent  paths 
could  be  created  by  reconnecting  the  Belvoir-Aberdeen  line 
between  SDAC  and  Aberdeen,  for  example. 

Such  load  splitting  by  using  bandwidth  routing  could  be 
useful  for  the  SHO-LPE  data  as  well.  A second  independent 
path,  from  Albuquerque  to  CCA  could  be  established  by  installing 
a line  from  Albuquerque  to  D0Ci3. 

The  development  of  this  type  of  routing  would  also  be  bene- 
ficial to  other  network  users  who  need  to  transmit  large  quantities 
of  data. 

It  is  rec cmmended  that  a combination  of  the  two  approaches 
outlined  above  be  considered.  A direct  line  from  SDAC  to  CCA, 
as  well  as  two  secondary  paths,  and  a high  bandwidth  routing 
algorithm,  would  provide  a great  degree  of  reliability.  If  the 
direct  line  should  fail,  the  routing  algorithm  would  be  able 
to  split  the  CCP-SIP  load  over  the  two  secondary  paths  in  such 
a manner  that  neither*  would  become  overloaded. 

Such  a solution  could  be  reached  progressively,  as  the 
seismic  network  takes  shape.  For  example,  bandwidth  routing 
could  be  implemented  as  the  first  parts  of  the  seismic  network 
come  on-line  (early  1976).  As  the  amount  of  seismic  data  sent 
to  the  SIP  increases,  the  nearly  direct  path  could  be  established 
inexpensively.  Finally,  as  the  seismic  network  nears  completion, 
the  direct  line  via  satellite  or  terrestrial  circuits  could  be 
established . 
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1 . SCOPE 

This  specification  establishes  the  performance,  design, 
development,  and  test  requirements  for  the  Seismic  Private 
Line  Interface  (SPLI)  prime  item. 


2.  APPLICABLE  DOCUMENTS 

The  following  documents  of  the  exact  issue  shown  form  a 
part  of  this  specification  to  the  extent  specified  herein. 
In  event  of  conflict  between  the  documents  referenced  herein 
and  the  contents  of  this  specif icaion , the  contents  of  this 
specification  shall  be  considered  a superseding  requirement. 


MIL-STD-1 88C , 24  November  1969 

"Interface  Message  Processor  - Specifications  for 
the  Interconnection  of  a Host  and  an  IMP",  Bolt, 
Beranek,  end  Newman,  Report  No.  1d22,  March  1974. 

"Final  Report  - Seismic  Network  Systems  Study", 
Bolt,  Beranek,  and  Newman,  Report  No.  2865,  9 
August  1974. 
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3.  REQUIREMENTS 

3.2  GENERAL  INTRODUCTION 

The  SPLI  (Seismic  Private  Line  Interface)  will  be 
implemented  as  part  of  a worldwide  seismic  data  collection 
and  processing  network.  Its  specific  task  will  be  to 
interface  a seismic  array  station  controller  to  an  ARPA 
Network  communications  link  with  the  Communications  and 
Control  Processor  (CCP)  in  the  seismic  network.  The  SPLI 
will  be  joined  to  the  ARPA  Network  link  by  connection  to  the 
nearest  Satellite  Interface  Message  Processor  (Satellite 
IMP)  or,-  in  an  expanded  overseas  Network,  possibly  to  either 
a TIP  or  an  IMP. 

The  design  specifications  given  here  for  the  SPLI  are 
based  on  the  data  formats  and  communication  protocol  defined 
in  BBN  Report  No.  2865  Appendix  A to  be  used  for 
communication  between  the  CCP  and  the  overseas  seismic 
s^tes.  SPLIs  are  required  for  three  sites  in  the  currently 
planned  seismic  network:  one  for  KSRS,  one  for  SITE  II,  and 
one  for  ILPA.  One  SPLI  design  is  given  for  both  the  KSRS 
and  SITE  II  sites  because  the  station  controllers  at  those 
sites  are  identical.  The  ILPA  station  controller  differs  in 
both  the  format  and  rate  of  data  output,  hence  a specific 
ILPA  SPLI  design  is  also  presented. 
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In  this  specification,  sections  describing  SPLI 
characteristics  that  are  based  on  design  criteria  peculiar 
to  an  individual  site  will  be  divided  into  two  parts:  one 
describing  the  KSRS/SITE  II  SPLI  and  another  describing  the 
ILPA  SPLI.  AH  other  sections  establish  design 
specifications  that  are  identical  for  both  kinds  of  SPLI. 


3.2  SYSTEM  OVERVIEW 

The  station  controller  at  a seismic  array  site 
generates  a real-time  data  message  once  each  second  that 
consists  primarily  of  one  second's  worth  of  seismic  data 
from  that  site  (KSRS/SITE  II  = 4800  bits,  ILPA  = 1200  bits). 
The  main  task  of  the  SPLI  is  to  transmit  these  real-time 
data  messages  via  the  ARPA  Network  to  the  CCP.  To 
accomplish  this  task,  a communications  protocol  and  message 
format  suitable  for  ARPA  Network  transmission  must  be  used 
by  both  the  SPLI  and  the  CCP.  A first  draft  of  such  a 
CCP-SPLI  protocol  has  already  been  defined  and  is  described 
m BBN  Report  No.  2865,  Appendix  A.  The  SPLI  specifications 
presented  herein  employ  a somewhat  modified  version  of  that 

CCP-SPLI  protocol  and  should  be  considered  as  superseding 
requires  nts. 

In  order  to  accomodate  any  short  duration  circuit 
outages  that  may  occur  in  communications  to  the  CCP,  the 
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SPLI  will  provide  limited  backup  buffering  for  the  real-time 
data  messages  that  it  sends.  The  CCP  must  receive  a real-time 
message  within  10  seconds  after  it  is  generated  by  the  station 
controller  and  thus,  assuming  an  overall  transmission  delay  of 
slightly  more  than  1 second  to  the  CCP,  the  SPLI  need  only  pro- 
vide buffering  for  up  to  8 one  second  real-time  messages. 

The  SPLI  will  also  respond  to  a special  HELLO  message  from 
the  CCP  by  sending  an  I -HEARD -YOU  message  to  the  CCP,  in  order 
to  allow  the  CCP  to  determine  whether  or  not  the  data  link  is 
properly  functioning.  This  status  assessment  scheme  will  be 
used  whenever  the  CCP  is  not  receiving  data  messages. 

Command  messages  to  the  KSRS/SITE  II  station  controller  and 
operatoi  messages  between  the  CCP  and  the  ILPA  SPLI  operators 
will  be  communicated  by  means  of  a Host  level  acknowledgement 
scheme.  That  is,  although  the  ARPA  Network  insures  reliable 
transmission  of  these  messages  through  the  IMP  subnetwork,  a 
'’higher''  level  message  acknowledgement  scheme  is  needed  to 
control  the  flow  of  these  messages  between  the  CCP  and  the  SPLI. 
This  Host  level  flow  control  is  necessary  in  order  to  minimize 
the  input  buffering  required  at  either  Host.  A Host  will 
acknowledge  the  receipt  of  such  a message  only  after  it  is 
ready  to  receive  the  next  message. 
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KSRS/SITE  II  SPLI: 

Two  options  are  given  here  for  the  configuration  of  the 
KSRS/SITE  II  SPLI.  The  first  option  assumes  that  the  SPLI 
will  bo  located  in  the  same  facility  that  houses  the  station 
controller.  The  connection  to  the  Satellite  IMP  will  be  as 
a Very  Distant  Host*  (VDH)  by  means  of  a leased  line  to  the 
satellite  ground  station  (or  TIP/IMP) . This  situation  is 
depicted  in  Figure  1 . The  second  opticn  assumes  that  the 
SPLI  will  be  located  at  the  satellite  ground  station  (or 
TIP/IMP)  where  it  will  be  connected  to  the  Satellite  IMP  as 
an  ordinary  Host.  The  station  controller  will  communicate 
witn  the  SPLI  by  means  of  a leased  line.  This  configuration 
is  depicted  in  Figure  2. 

In  both  configurations,  a leased  line  is  needed  between 
the  facility  housing  the  station  controller  and  the 
satellite  ground  station  (or  TIP/IMP)  which  will  contain  the 
Satellite  IMP. 


ILPA  SPLI: 


* see  Appendix  F of  BBN  Report  No.  1822. 
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The  ILPA  SPLI  will  be  located  in  the  same  facility  as 
the  station  controller  and  will  be  connected  to  the 
Satellite  IMP  by  means  of  a leased  line  to  the  satellite 
ground  station  (or  TIP/IMP) , employing  the  error-protected 
VDH  protocol.  Operator  messages  will  be  communicated  with 
the  CCP  operator  using  the  console  connected  to  the  SPLI. 
This  configuration  is  shown  in  figure  3. 
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Figure  1 . KSRS/SITE  II  SPLI  Configuration  - Option  1 
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Figure  2.  XSRS/SITE  II  SPLI  Configuration  - Option  2 
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3.5  SPLI/CCP  MESSAGE  FORMATS 

The  message  format  that  is  to  be  used  in  accordance  with 
the  communication  protocol  between  the  SPLI  and  the  CCP  is  shown 
in  Figure  4A.  It  consists  of  a 2-word  Host-IMP  leader,  a 1-word 
message  class  identifier,  and  a message  body. 

The  specific  format  of  the  32-bit  Host-IMP  leader  that  is 
to  be  used  with  messages  transmitted  by  the  SPLI  is  given  in 
Figure  4b.  The  Destination  Address  used  will  be  that  of  the 
CCP  either  connected  to  the  oDAC  Tip  or  the  SDAC  IMP,  determined 
by  the  SPLI  as  described  ir.  a following  section.  The  message 
ID  is  used  for  Host/IMP  message  identification. 

A message  received  from  the  CCP  by  the  SPLI  wi  1 be  considered 
as  valid  only  if  the  Host-IMP  leader  conforms  to  figure  4c. 

The  Source  Address  field  (bits  9-16)  except  a HELLO  message  must 
contain  the  CCP  address  that  is  currently  being  recognized  by 
the  SPLI  (as  specified  below) . The  SPLI  shall  discard  all  ARPA 
Network  Satellite  IMP  messages  it  receives  that  contain  an  invalid 
Host-IMP  leader. 

It  is  important  that  the  SPLI  maintains  a responsive 
connection  with  the  ARPA  Network.  That  is,  it  must  receive 
incoming  messages  held  by  the  Satellite  IMP  with  highest  priority 
in  order  not  t > load  down  that  node  of  the  network.  If  the  SPL.T 
fails  to  take  a message  within  a reasonable  time,  the 
Satellite  IMP  will  declare  it  dead. 

The  16-bit  message  class  identifier  is  used  to  differentiate 
between  the  several  types  of  messages  that  are  communicated 
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(b)  Format  of  Host-IMP  Leader  from  SPLI  to  CCP 
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(c)  Format  of  Host-IMP  Leader  from  CCP  to  SPLI 


Figure  4.  Message  Format  used  between  the  CCP  and  the  SPLI 
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between  the  SPLT  and  the  CCP . The  classes  of  messages  that  are 
used,  along  with  the  definitions  of  the  corresponding  message 
bodies,  are  shown  in  Figure  5 for  the  KSRS/SITE  II  and  in  Figure 
6 for  the  ILPA  SPLI. 

Class  0 messages  are  sent  to  the  CCP  by  the  SPLI  once  each 
second  and  contain  the  real-time  data  messages  generated  by  the 
station  controller. 

Unusual  delays  and  circuit  outages  will  cause  a backlog 
of  Class  0 messages  in  the  SPLI  output  queue.  As  explained  above, 
the  SPLI  will  provide  buffering  for  only  eight  of  such  backloqged 
Class  0 messages.  Assuming  an  overall  transmission  delay  of 
slightly  more  than  1 second,  this  will  insure  that  the  oldest 
saved  message  will  be  processed  by  the  CCP  within  the  required 
10  second  limit.  An  outage  longer  than  8 seconds  will  cause 
the  SPLI  to  overwrite  the  oldest  of  the  9 one  second  real-time 
message  buffers. 

Class  1 (Acknowledgement)  messages  are  sent  whenever  a host 
has  received  a Class  5 or  6 message  and  is  ready  (i.e.  it  has  the 
necessary  buffer  space)  to  receive  another.  The  body  of  an 
Acknowledgement  message  contains  the  1 word  unique  identifier 
of  the  particular  message  that  is  being  acknowledged.  When 
the  connection  is  first  declared  alive,  it  shall  be  assumed  that 
the  other  host  is  prepared  to  receive  one  Class  5 or  6 message. 
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(a)  Messages  from  the  CCP  to  the  KSRS/SITE  II  SPLI 
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Figure  5.  Message  Classes  between  CCP  and  KSRS/SITE  II  SPLI 
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Figure  6.  Message  Classes  between  CCP  and  ILPA  SPLI 
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' £'AHD  Y0U>  messages  have 

~ -y  and  «.  when  no  bei„9  rMelvad  ^ ibe 

fro.  ...  parricular  sUo.  tho  spii  raMivej  ^ uelm 

r.  respond  with  hi,he,t  ptiority  py  # ^ 

i-.iEAM.-rou)  passage.  Tta  u s HoIt_to.Ho>t 

acknowledgment  of  the  ™r.!pondl„,  „Elt0.  Ihe  ^ ^ 

recognized  CCP  address  to  the  source  address  of  the  HELLO 

A C. ass  4.  „ost  goi„,  down  ^ ^ ^ ^ 
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the  message  was  originally  sent.  The  structure  of  this  time 
code  is  depected  in  Figure  7 and  consists  of  eleven  BCD  4-bit 
subfieids  (year-tens,  year-units,  day  hundreds,  ...,  second- 
units)  . 

The  ILPA  SPLI  will  generate  a unique  identifier  for  each 
Class  5 message  that  it  sends  to  the  CCP  by  using  a sequential 
16-bit  counter.  When  a Class  5 message  is  formed,  the  value 
of  the  counter  is  used  as  the  16-bit  unique  identifier  field  and 
then  the  counter  is  incremented.  At  initialization,  the  counter 
is  set  to  the  low  order  16  bits  of  the  time  code. 

When  an  end  receives  a Class  5 message  it  must  save  a copy 
of  the  unique  identifier  as  well  as  returning  a corresponding 
Acknowledgement.  If  the  Acknowledgement  is  delayed  too  long  or 
becomes  lost  then  a duplicate  Class  5 message  will  be  received. 
Such  duplicates  will  be  detected  by  noting  that  their  unique 
identifiers  are  not  greater  than  the  one  that  has  last  been  saved. 
At  initialization,  the  saved  identifier  register  is  set  to  zero. 
Acknowledgements  will  be  returned  for  the  duplicate  messages,  but 
the  saved  unique  identifier  will  not  be  changed  and  the  duplicates 
will  be  discarded. 

Messages  communicated  between  the  SPLI  and  the  CCP  will  be 

sent  with  the  following  priorities,  from  highest  to  lowest: 

Class  3 ( I-HEARD-YOU) 

Class  2 (HELLO) 

Class  0 (real-time  data) 

Class  1 (Acknowledgement) 

Class  5 or  6 (Commands  or  Operator  Message) 
Class  4 (Host  going  down) 
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Figure  7,  Detailed  Structure  of  the  Time  Code  Field 
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3.6  STATION  CONTROLLER/SPLI  INTERFACE 
KSRS/SITE  II  SPLI: 

Seismic  data  is  output  from  the  KSRS/SITE  II  station  con- 
troller at  4800  bits/second  (synchronously)  in  accordance  with  the 
low  level,  serial;  digital  data  specification  of  MIL-STD-188C . 

The  logical  format  of  a one  second  300  word  data  frame  is  shown 
in  Figure  8.  The  SPLI  will  transmit  a data  / rame  to  the  CCP  in 
a Class  0 message.  The  SPLI,  will  compute  a single  cnecksum  on 
the  message  and  add  it  at  the  end  of  the  message. 

The  KSRS/SITE  II  SPLI  will  receive  Class  6 messages  from 
the  CCP  containing  commands  to  the  station  controller.  This 
command  data  will  be  output  to  the  station  controller  at  75 
bits/second  (asynchronously)  in  accordance  with  MIL~188C.  The 
logical  foj.  ^at  of  such  a command  is  shown  in  Figure  9.  Option  1 — 
with  the  SPLI  located  in  the  same  facility  as  the  station  controller 
(see  Figure  1) — permits  direct  connection  between  the  SPLI  and 
the  station  controller.  The  SPLI  will  require  both  a 4800 
bits/second  synchronous  modem  simulator  interface  and  a 75  bits/ 
second  asynchronous  device  interface. 

Option  2 — with  the  SPLI  located  at  the  satellite  ground 
station  (see  Figure  2)  requires  a leased  modem  line  connection 
between  the  SPLI  and  the  station  controller.  The  SPLI  will 
require  both  a 4800  bits/second  synchronous  line  interface  and 
a 75  bits/second  asynchronous  device  interface. 
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ILPA  SPLI: 

Seismic  data  is  output  from  the  ILPA  station  controller 

at  1200  bits/second  (asynchronously)  in  accordance  with  EIA-RS-232C. 

Data  will  be  transmitted  in  11-bit  bytes,  each  byte  consisting  of: 

start  bit 
8 bits  of  data 
odd  parity  bit 
stop  bit 

Only  the  8-bit  portion  of  the  byte  will  be  included 
in  the  real-time  data  frame  sent  to  the  CCP . The  logical  format 
of  the  one-second  51  word  data  frame  received  by  the  SPLI  from 
the  station  controller  is  shown  in  Figure  10. 

The  SPLI  will  check  the  odd  parity  on  each  incoming  byte 
and  keep  a count  of  the  number  of  parity  errors  detected  during 
each  one  second  frame  of  data  input.  This  count  will  be  kept 
in  a 16-bit  word  and  will  be  appended  (as  word  52)  to  the  one 
second  data  frame  that  is  sent  to  thc  CCP  each  second  in  a 
Class  0 message.  The  SPLI  will  compute  a polycode  redundancy 
check  on  the  one  second  message  to  be  transmitted  and  will  add 
it  to  the  end  of  the  message. 

The  ILPA  SPLI  will  be  connected  directly  to  the  station 
controller  and  thus  requires  a 1200  bits/second  asynchronous 
device  interface. 
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1 

• 

i 

i 

i 

• 

HEADER  ! 

REAL-TIME 

! WAVEFORM 

DATA 

! ERROR 

i 

IDLE 

i 

i 

• 

DATA 

! OR  ASCII 

i 

TEXT 

! CODE 

i 

i 

• 

i 

• 

CODE 

96  bits 

4672 

bits 

— 

16  bits 

14-1 

bit 

(a)  Real-Time  Message  Format  from  KSRS  and  SITE  II 


i i 

• • 

! SYNC  ! 

i i 

i 

ID  I 

i 

i 

• 

STATUS  ! 

i 

UNDEFINED 

TIME  CODE 

16  bits  8 

bits 

8 bits 

20  bits 

44  bits 

(b)  Format  of  Header  in  Real-Time  Message  from  KSRS  and  SITE  II 


Figure  8.  Real-Time  Message  Format  from  KSRS  and  SITE  II 
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i 688  bits*- 


7 bytes 


< 72  bytes* 


7 bytes 


* except  for  "MESS"  command  which  can  contain  text 
of  up  to  150  lines  of  72  characters  each 


BODY  OF  COMMAND 


i 

• 

I 

! 

ft 

• 

i 

• 

i 

COMMAND 

i 

REQUEST 

i 

• 

FUNCTION 

i 

• 

TYPE  I 

OPTION 

! 

PARAMETERS  ! 

CODE 

1 

ID 

i 

CODE 

i 

CODE  ! 

CODE 

! 

! 

l 

l 

i 

I 

! 

! 

(ASCII  CHARACTERS) 


START  

CODE  I SOH  I SOH  ! CR  ! CR  ! LF  I NUL  i NUL  ! 


COMMAND  

CODE  ! / ! / ! 


REQUEST  

ID  IH1Q!QIQ!QIQ!  , ! 


TERMINATION  

CODE  ! CR  ! CR  i LF  ! NUL  ! NUL  ! EOT  1 EOT  ! 


Figure  9.  Command  Message  Format  to  KSRS  and  SITE  II 
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i* 

Length 

— — — — — — ( wo  T d si—* 

Contents 

Description 

m ■*- 

ri  . 

| 

8 i 

1 

F09A  (IN  HEX) 

SYNC 

r 

1 

'IL'  (IN  EBCDIC) 

STATION  CODE 

i ■ 

One  status  byte*  each 

4 

for  seven  LP  sites 

DATA  STATUS 

| 

and  one  SP  site 

r * 

3 

OYYDDDHHMMSS 

TIME  CODE 

1 

i j 

4 • 

21 

1 FRAME 

LP  DATA 

21  CHANNELS 

1 

20 

20  FRAMES 

SP  DATA 

* * 

1 CHANNEL 

1 

! 

1 

C8C8  (IN  HEX) 

END  MESSAGE 

{ 

* Each  data  status  byte  will  have  the  format: 
Bit  On  Description 


0 Sync  error  (remote  site  to  CRS) 

1 Faulty  or  missing  LP  data 

2 Calibration  in  progress 

3 Deleted  from  beamforming  by  operator 

4 Faulty  or  missing  SP  data 

5 Extraneous  data 


Figure  10.  Real-Time  Message  Format  from  ILPA  station  controller. 
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3. ,7  ILPA  SPLI  TTY  INTERFACE 

The  ILPA  SPLI  operator,  must  be  able  to  exchange  text 
messages  with  the  CCP  operator.  This  implies  that  the  SPLI 
be  interfaced  with  a low-spaed,  hardcopy,  keyboard-equipped 
terminal . 

A Class  5 message  received  by  the  SPLI  will  contain  up 
to  4800  bits  of  an  ASCII  text  message  from  the  CCP  operator.  The 
time  code  identifier  of  the  message  should  be  printed  on  the 
SPLI  console  preceding  the  ASCII  text. 

The  SPLI  will  store  text  entered  by  the  SPLI  operator  in 
a 80  byte  buffer.  The  SPLI  will  transmit  the  contents  of  a 
buffer  in  a Class  5 message  to  the  CCP  when  either  the  buffer 
is  filled,  a carriage  return  is  typed,  or  an  end-of-transmission 
character  is  typed. 

To  indicate  a buffer  overflow  when  the  buffer  is  full,  the 
SPLI  should  ring  the  bell  and  should  type  a "/"  character  for 
each  character  that  is  typed  wherever  the  text  buffer  is  full. 
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3.8  SPLI/SIMP  INTERFACE 
XSRS/SITE  II  SPLI: 

Option  1 — with  the  SPLI  located  in  the  same  facility  as  the 
station  controller  (see  Figure  1) --requires  a dedicated  full 
duplex  synchronous  modem  line  between  the  SPLI  and  the  SIMP. 

The  SPLI  will  be  connected  using  the  Very  Distant  Host  ( VDH) 
interface  and  will  employ  rhe  error-controlling  VDH  line 
protocol  described  in  BBN  Report  No.  1822,  Appendix  F. 

In  addition  to  the  bandwidth  required  for  the  4800 
bits/second  of  real-time  data,  the  leased  line  from  the  SPLI 
to  the  SIMP  must  provide  sufficient  excess  bandwidth  for: 

1.  other  classes  of  CCP-SPLI  messages 

2.  ARPANET  and  VDH  overhead  (see  Table  I) 

3.  VDH  packet  retransmission 

4.  catch-up  transmission  of  backlogged  real-time  data 
An  estimate  of  1.  and  2.  is  computed  in  Table  II. 

The  necessary  bandwidth  then,  assuming  ideal  circuit  bahavior, 
is  approximately  5060  bits/second. 

To  allow  for  3.  and  4.,  a minimum  leased  line  bandwidth  of 
7200  bits/second  is  recommended. 

0ption2--with  the  SPLI  located  at  the  satellite  ground  station 
(see  Figure  2)  permits  direct  connection  of  the  SPLI  to  the 
SIMP  as  an  ordinary  Host.  The  specific  Host  interface  required 
for  the  SPLI  as  described  in  detail  in  BBN  Report  No.  1822. 
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TABLE  I 

ARPANET  and  VDH  Overhead 

(where  M = length  of  message  in  words  without  Host-IMP  leader) 


component 


Host-IMP 


VDH  packet  headers 


VDH  DLE  repetition 


SYN,  SYN  DLE,  STX,  DLE,  ETX. 


bits 


32 


^ 256  I 

48 


X 16 


on  the  average 


VDH  checksum 


24 
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TABLE  II 


KSRS/SITE  II  SPLI  to  SIMP  Excess  Bandwidth  Requirements 


message 

M 

overhead 

messages/ 

total  of 
1.  and  2. 

class 

(words) 

(bi ts) 

second 

(bits) 

0 302 


224 


5056 


1 


4 


144 


1 

16 


4 


TOTAL. 


5060 
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ILPA  SPLI: 

The  ILPA  SPLI  will  require  a dedicated  full  duplex  syn- 
chronous  modem  line  to  the  SIMP  to  which  it  will  be  connected  as 
a Very  Distant  Host  (VDH) . The  SPLI  will  be  equipped  with  a 
VDH  interface  that  uses  the  error-controlling  VDH  line  protocol 
described  in  BBN  Report  No.  1822,  Appendix  F. 


In  addition  to  the  bandwidth  required  for  the  832 
bits/second  of  real-time  data,  the  leased  line  from  the  SPLI 
to  the  SIMP  must  provide  sufficient  excess  bandwidth  for: 


1. 

other  classes  of  CCP-SPLI  messages 

2. 

ARPANET  and  VDH  overhead  (see  table 

I) 

3. 

VDH  packet  retransmission 

4. 

catch-up  transmission  of  becklogged 

real-time  data 

expected  total  of  1.  and  2.  is  computed  in 

table  III. 

The  necessary  bandwidth  then,  assuming  ideal  circuit  behavior, 
is  340  bits/second. 

for  3.  and  4.,  a minimum  leased  line  bandwidth  of  2400 
bits/second  is  recommended. 
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TABLE  III 


ILPA  SPLI  to  SIMP  Excess  BAndwidth  Reouirements 


message  M 

class  (words) 


overhead 

(bits) 


messages/ 

second 


total  of 
1.  and  2. 
(bits) 


54 


144 


144 


305 


224 


1008 


1 

16 


13 


1 

16 


319 


TOTAL 


1340 
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3 . 9 ENVIRONMENT 

The  SPLIs  will  operate  over  a temperature  range  of 
0 to  4 5°C  (32°  to  110°F)  and  humidity  from  0 to  90%  with 
condensation.  The  equipment  will  be  able  to  be  stored  or 
shipped  over  a range  of  -20°  to  50°C  (0°  to  . 20°F) . 


no 
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•***“■» 


3 
I 
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SPLI 


IMP 


CCP 


KSRS 


ILPA 


SDAC 


SIMP 


abbreviations 


se  smic  Private  Line  Interfac. 


Interface  Message  Processor 


Communication  and  Control  Processor 


Korean  Seismic  Research  Station 


Iranian  Long  Period  Arra' 


Seismic  Data  Analysis  Center 


Sa  allite  Interface  Message  Proc 


essor 
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